ServiceComb 微服务开发框架介绍

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 开源的主要想法有几个：

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

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

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

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

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

ServiceComb 项目介绍

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

1.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 等集成使用。

2.service-center

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

管理的需要

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

2.支持微服务黑白名单管理

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

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

5.支持微服务依赖关系管理

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

高可靠设计

• 故障模式

• 实例缓存

• 心跳保活

• 分区容错

3.saga

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

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

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

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

本文转载自华为云产品与解决方案公众号。

原文链接：https://mp.weixin.qq.com/s/9D59SU33pWxGO5KtaBZr6g