本文根据2018-10-20北京OSCAR开源先锋日演讲内容整理。

ServiceComb项目背景和开源

ServiceComb项目源于华为微服务引擎（CSE）。CSE开发的目的是加快公司业务云化和微服务化。在CSE之前，公司还有非常多的微服务框架，包括OSS 3.0，CloudSOP，DSF，HSA等等。CSE借鉴和继承了这些框架的优点，并着重从如下方面解决微服务面临的问题：

1.       微服务通信性能。

2.       微服务运维和治理。性能监控、流量控制、隔离容错、灰度发布等。

3.       遗留系统改造。

4.       配套DevOps，以开发框架为中心，完善全生命周期的DevOps工具集。包括服务接口兼容性管理、契约测试、开发流水线、统一运维等。

ServiceComb项目于2017年5月在北京LC3会议上宣布开源，同年12月成为Apache软件基金会孵化项目。ServiceComb开源的主要想法有几个：

1.       让应用上云更简单。开发环节是一个产品投入很重要的环节，也是人力成本很高的一个环节。选择一个封闭的开发框架，需要投入大量的支撑人力。通过开源，开发者可以自助完成基本问题的分析，并通过其他使用者提供的经验，解决产品问题。

2.       贴心的开发者服务。提供一种无处不在的计算服务，将基础中间件和运维管理能力服务化，开发者可以在自己的办公室、家里、路途中轻松访问开发工具，完成功能开发和上线部署。这个想法影响到了相关中间件服务的设计思路，只要存在连通的网络，即可配合开发SDK轻松访问这些中间件，而不需要在黑盒子里面部署自己的应用。这种思路可以加快一些用户的创新想法得到快速的实现。比如一个突如其来的点子，需要做一个原型系统验证，就可以直接下载SDK开始工作，而不需要为其他服务准备环境。

开源后也带来了一些意想不到的正向作用：

1.       促进了软件质量的提升。开源软件团队在质量管理方面带了一个好头，这些实践经验能够被其他团队看到，间接的促进了其他团队开发能力的提升。开源团队也从社区学到了非常多有些的开发实践，比如基于git、github的协作流程、Apache Way的沟通、决策流程等。

2.       增强了公司被外界的感知和影响力。

ServiceComb项目介绍

ServiceComb由3个子项目组成。 java-chassis、service-center和saga。

·         java-chassis

Java语言微服务SDK，含服务契约、编程模型、运行模型与通信模型四个部分，具备负载均衡、容错熔断、限流降级、调用链追踪等全面微服务治理能力。下面是总体的架构设计图：

框架适配了常见的编程模型。在Consumer端，支持PRC和Spring RestTemplate两种接口；在Provider端，支持RPC、JAX-RS和Spring MVC三种接口。同时编程模型和通信模型分离，这使得通过这个模型，我们可以兼容和适配REST、gRPC、其他自定义二进制协议等常见三方系统协议。实际使用的最广泛的是REST，也是整个框架支持的最完备的部分。ServiceComb的REST是目前最方便使用的实现，比Spring MVC、Jersery等提供了更加友好的RPC编程支持，并是仅有的统一了客户端和服务端处理链的实现，使用其他框架，基本都需要针对客户端治理和服务端治理采用不一样的技术独立实现。

java-chassis的设计核心理念是 “全面开放，使用标准协议，架构易于拆分和扩展，对开发人员友好，可以与业界其他主流框架互通集成”，除了整体架构上的开放型，在和外部系统集成方面也是非常容易的。能够很好的和Spring 4, Spring 5, Spring Boot 1, Spring Boot 2、J2EE container等集成使用。

·         service-center

提供微服务实例注册、发现能力的服务。service-center提供一套标准的RESTful API对微服务元数据进行管理。

管理的需要

l  支持逻辑多租的微服务实例隔离管理

l  支持微服务黑白名单管理

l  支持长连接监听微服务实例状态变化

l  支持OpenAPI规范微服务契约管理

l  支持微服务依赖关系管理

l  提供Web portal展示微服务管理界面

高可靠设计

故障模式

实例缓存

心跳保活

分区容错

·         saga

提供分布式事务开源解决方案。解决分布式场景下事务性能、可靠性以及多实例高可用场景下复杂性等难题，并提供简单的API方便用户使用。分布式事务管理一直是开发领域最复杂的逻辑之一，如何保证数据一致性，如何设计更好的并发控制逻辑以解决性能瓶颈，常常需要非常复杂的技巧。在数据库事务中，可以通过ACID和数据库锁来解决一些业务问题。在分布式场景下，特别是高可用多实例部署情况下，一些问题变得更加突出：

1.       操作变得更加不可靠，容易发生故障。在本地事务情况下，一般不出现断电等特殊情形，事务故障就不会发生。分布式场景下，网络连接不可靠、实例发现的非实时性等让故障变得更加普遍。

2.       并发控制代价更高。分布式锁造成系统性能低下，故障变多更容易出现死锁。

Saga系统分为两部分：Alpha和Omega。Alpha是独立的服务，扮演事务协调器的作用。Omega作为开发组件，和业务进程运行在一起。

SAGA通过柔性事务(BASE)替代刚性事务(ACID)来解决分布式事务问题，实现了Saga和TCC两种事务协议。SAGA在架构设计上是开放的，Alpha定义了事务协议，Omega可以在不同的开发框架和开发语言上进行扩展。目前提供了ServiceComb java-chassis、Spring Feign、Spring RestTemplate、Dubbo、C#等开发方式实现，其中C#语言是其他开发者贡献的，不在ServiceComb项目中。

开源与商业的良性互动

成功的开源项目需要有良好的设计和优雅的实现。但这只构成其中的一部分，甚至是很小的一部分。为开源项目设计好长期发展目标、质量保证措施、推广计划和长期资源投入是必不可少的。项目运作机制和文化建设也是非常重要的方面。

ServiceComb在项目管理上独创One Branch机制，持续的将商业特性贡献给社区，保证社区版本和商业版本代码同源。开源软件一般都是免费使用，因此在服务上更多的强调自助和社区帮助。通过One Branch机制，开发者可以用使用开源软件的成本，得到更好的版本管理和质量管理服务。

同时商业团队也从开源社区吸取优秀实践，践行Apache Way，改善内部研发和沟通机制，突出优秀贡献者，解决沟通障碍。比如将github优秀的git流程引入内部研发流程，遵从Apache Way投票机制，解决在是否实现或者修改某些功能特性上的争执，并取得一致的意见。

代码质量管理

•       合规检查

•       集成测试

•       代码规范

项目运作方面将华为优秀的研发管理和质量管理工具带入社区，保证开源代码的质量。通过华为Fossid等三方软件管理工具，识别三方软件在合规上的使用风险；使用PDM等系统管理三方件漏洞。利用华为提供的各种资源，搭建多条自动化测试流水线，对代码进行自动化验证；结合华为内部的实践，利用JIRA规范管理需求、issue等，并由PMC成员检视所以代码合入。在三方件管理、代码规范、流水线建设和测试自动化率方面，ServiceComb项目领先于大部分开源项目，其中包括使用非常广泛的项目，如spring cloud、dubbo、vert.x等。ServiceComb严格的质量管理体系，质量效果也是非常好的，大量用户使用经验表明，ServiceComb的缺陷率远远低于开源软件平均水平。

ServiceComb服务治理能力概览

负载均衡能力

ServiceComb提供非常强大的负载均衡能力，包括兼容性和协议分组、负载均衡策略和过滤器、实例隔离和重试等。提供分组路由功能主要是解决多AZ部署场景下的路由选择优先和容错能力。

•       改进的Ribbon实现

1.       开源的Ribbon实现不支持基于请求参数的Filter扩展，ServiceComb改进了Filter的接口定义，增加了Invocation作为输入参数，可以支持请求参数的Filter。这种机制是实现灰度发布的一个重要基础。

2.       独立的Filter和Rule扩展。Ribbon组件本身需要组合Filter、Rule、LoadBalancer来实现特定的负载均衡策略，ServiceComb改善后，可以独立扩展Filter或者Rule，并且能够独立组合使用。

调用链跟踪能力

•       目前业界流行的调用链标准是Zikpin。具体实现方式有两种：一是侵入式的API，采用brave API来扩展；而是非侵入式的埋点，比如PinPoint方式。这两种方式ServiceComb均支持。

•       为了弥补Zipkin的不足，ServiceComb独创了基于事件的非侵入式埋点，解决上面方式调用链数据过于粗超（比如没办法显示在性能分析过程中非常有用的数据，包括请求排队时间、业务处理时间、网络读/写时间等细粒度的分析数据）

隔离舱

•       隔离舱主要用于解决微服务调用可能产生的雪崩效应，以及解决不同请求并发访问时候的总体吞吐量问题

•       目前广泛使用的机制是Netflix开源的Hystrix。

•       ServiceComb改善了Hystrix，通过Handler，集成了Hystrix，用户不需要开发代码，通过配置即可给某个接口配置隔离舱，可以配置接口的熔断策略和隔离策略。

•       为了解决Hystrix的性能问题，ServiceComb在通信层自带隔离舱功能，可以配置业务逻辑处理线程池，直接将不同逻辑隔离到独立的处理单元。避免了Hystrix自创线程池的低性能。

Edge Service

边缘网关有几个作用：负责请求汇聚，将业务系统藏在盒子里面，扮演一个高效的路由器的作用。边缘网关可以进行集中式鉴权处理。边缘网关可以弹性伸缩，跟随业务规模的增长，扩展实例。

•       提供纯异步处理的边缘网关服务，相对于Zuul大大提高了性能

•       基于ServiceComb的治理模型，能够动态管理接口兼容性，实现接口兼容性转发

•       通过Dispatcher进行扩展，开发更加灵活

房屋抢购系统

买房系统的主要业务流程是实现一个抢购操作。抢购操作涉及扣除定金、销售房源和支付3个分布式操作，采用Saga提供的TCC事务来协调分布式事务。

通过动态配置构造一个故障

演示登陆CSE，通过配置中心下发一个配置项，系统程序会读取这个配置项，构造支付失败的场景。支付失败事务会进行回滚，最终查看数据是一致的。

通过zipkin跟踪调用情况

Zipkin是一个开源的调用链系统实现，通过zipkin，可以查看请求的时延等情况。调用链跟踪是通过一个Hanlder进行实现的，实现Handler后，需要经过步骤启用：

1. 引入依赖包

2. 配置Hanlder      Chain

参考文献

1. ServiceComb开发性设计: https://bbs.huaweicloud.com/blogs/1fc9427c088611e89fc57ca23e93a89f

2. Saga分布式事务解决方案与实践: http://servicecomb.apache.org/cn/docs/distributed-transactions-saga-implementation/

3. 打造一个企业级应用的微服务开发框架（上）: https://bbs.huaweicloud.com/blogs/8c98dc59412611e89fc57ca23e93a89f

4.  打造一个企业级应用的微服务开发框架（下）:  https://bbs.huaweicloud.com/blogs/0a1a862f412611e89fc57ca23e93a89f