谈谈华为微服务解决方案与实践（中）

华为微服务解决方案是什么

华为微服务产品包含一套微服务开发框架、一站式微服务监控与治理平台以及一系列配套的微服务开发工具，主要功能如下：

• 基于契约(Open API)的开发模式：让微服务的开发、测试、文档、协作和管控活动标准化、自动化

• 高性能REST/RPC微服务开发框架：打包了微服务注册、发现、通信和治理等基础能力，开箱即用

• 一站式微服务治理控制台：提供微服务负载均衡、限流、降级、熔断、容错、错误注入等治理能力

• 非侵入式微服务：提供Mesher服务，可实现多语言微服务解决方案，以及遗留系统零改造微服务化

• 多样化微服务安全管控能力：提供认证鉴权、黑白名单等能力保障微服务访问安全

• 灰度发布支持业务平滑升级：支持使用接口任意参数（例如用户群组、用户类别、用户所属区域等等）定义微服务灰度发布规则

• 微服务调用追踪：提供微服务实例和接口级吞吐量、时延和成功率的实时监控及调用链分析

这套微服务产品完全是从公司各条业务战线上提炼而来，自始至终贯彻易用、开放、多场景和企业级的理念进行设计和演进的：

• 因为要服务于内部数万微服务开发者，这些开发者的能力参差不齐，如果不易用门槛不放低，使用和推广成本就会非常高；

• 因为要服务于内部各种不同类型的业务，如运营商、企业、消费者、流程IT等，如果架构不开放就无法做到基于一套框架灵活定制按需使用；

• 因为除了要满足新业务开发、也要满足老业务平滑迁移、还要满足和三方系统方便集成，如果不能适应多场景，不考虑平滑演进，应用范围就会非常的窄；

• 因为公司基本上所有业务都是全球交付，在性能、可用性、安全性上不做到企业级就根本没法商用。同时基于华为聚焦微服务技术领域多年的持续投入，目前已在多个方面做到了业界或国内首创，例如：面向国内提供了首个多语言微服务框架，首个商业版Service Mesh产品，并大规模应用于生产环境；业界首个进入Apache开源社区的微服务框架ServiceComb。

另外，我们也有一个专业的微服务评估（参考下图，已在华为云上开放自助评估服务）和咨询团队，能帮助企业完成从微服务适用性评估、服务划分到落地实施（平台和工具使用支撑）等微服务化转型端到端的解决方案。

华为微服务框架与开源框架的区别

可能还有很多人会有这样的疑问：我之前用开源框架好好的为什么华为还要重复造个轮子？

这个就要回顾华为微服务框架的发展历程了，起初华为也是在开源框架的基础上进行开发并投入使用，但是在支撑公司内部各种业务的过程中发现了不少问题，简单罗列几点：

1. 语言绑定。当前开发语言层出不穷，其本身就说明业务对开发语言是有诉求的（不同的业务需要合适的语言来开发），同时特别是在云服务生态里，对不同语言开发的微服务能够方便的互通成了基本要求；

2. 协议支持单一。基本要么只支持RPC，要么只支持REST，而实际有的场景仍然在使用或需要传统的Web Service（例如SOAP等等）协议，有的场景为追求极致的性能都有自己深度定制的私有协议，有的场景面向不同接入方式需要同时发布多种协议的服务接口；

3. 性能和易用性问题。例如Spring Cloud把微服务的各种能力（如注册发现，路由管控，能力接入等等）都拆分成了独立的部件由使用者根据实际场景来组合使用，其本身确实提供了极大的灵活性，但灵活性的背面是复杂性，对人员能力的要求较高，同时其性能（例如并发量和时延）并不乐观，在一些要求苛刻的场景显得力不从心。

总之，太多经验表明，把一堆开源软件包变成可用，再到可商用，中间有太多的坑需要填平，华为就是这样填着填着，后来发现基本变成了一个新的东西。事实上，我们在开源基础上提供了十多项关键能力的增强，这些也都是从我们经历过的一些活生生的经验教训，交了无数学费后总结而来。

对比项	华为云微服务引擎	基于开源Spring Cloud自建
管理界面	提供一站式微服务管理控制台，包含服务目录、服务治理、服务配置、事务看板及新服务创建等简单易用的Web操作界面	需自行开发UI控制台，代码量2万多行
开发语言	支持JAVA、Go、PHP、.NET、Python、NodeJS及其他多种主流开发语言	只支持JAVA
通信协议	REST/RPC/gRPC/可扩展	REST
Service Mesh	提供商业版Mesher，支持一键式部署	无
易用性	只需导入华为微服务SDK即可享受各种服务治理和管控能力，包括负载均衡、故障隔离、容错机制、流量控制、调用链跟踪和服务状态仪表盘等，这些功能与业务代码完全解耦，用户只需专注业务开发	基于Spring Boot/Cloud组件构建，需要集成验证Hystrix、Ribbon、Zipkin、Prometheus等大量三方组件，门槛高，学习周期长
服务注册	提供了对微服务静态元数据丰富的管理能力，例如支持应用>微服务>实例的层次关系管理、版本管理、tag管理、灰度发布以及服务拓扑，同时提供了对大规模企业级微服务管理	提供Eureka组件，需自行开发封装成服务使用，仅是管理动态路由数据
动态配置	提供多维数据建模的方式组织配置信息，对于配置信息的描述能力更强，扩展能力更好。另外同时支持了push和pull的配置变更通知方式，实时性更好	提供Spring Cloud Config组件，需自行开发封装成服务使用，配置描述能力弱，且实时性不好
服务治理	支持更细粒度（接口级）的服务治理能力。并且实现了实例访问错误重试和隔离、多数据中心间服务发现的优先级等其他治理能力。另外，对于这些开源库提供的原生治理方式进行了妥善的封装，可以通过配置的方式进行使用而不必再进行编码	仅提供Hystrix等开源组件，需自行开发封装成服务使用，只支持服务粒度隔离
轻量级网关	支持Restful请求汇聚及转发，支持服务映射、请求解析、加密解密、鉴权等自定义能力，网关服务本身也可被治理	基于Zuul构建网关，性能是短板，治理能力需要业务集成大量三方件来实现
灰度发布	支持按权重和接口参数（例如用户群组或用户所属区域等等）定义微服务灰度发布规则	无
仪表盘	提供基于微服务>实例>接口多层次的应用级指标监控，如吞吐量、平均时延、请求等等	无
部署	即开即用（秒级）	需基于开源组件自行开发和部署服务中心、配置中心、治理中心以及控制台，费时费力
扩容	通过控制台自助式升降规模（秒级）	需要手工进行实例扩容，数据迁移等等
异地容灾	支持AZ基本高可靠	搭建难度大，技术要求高，需自行开发HA

华为微服务Service Mesh解决方案

ServiceMesh是当前业界比较火的一个热点技术，华为也是国内最早把这个技术落地，推出商业版产品，并大规模应用于生产环境的云服务提供商。其实技术归技术，真正要有用还是得拿用它来真正解决现实问题。目前主要用来解决客户的两类问题：

第一类是那种使用一些语言开发微服务（如php、.net、nodejs、python等），但业界没有合适的微服务框架能直接使用，所以只能使用这种代理方式来解决微服务的注册发现以及路由管控等问题；

第二类是那种有一大堆遗留应用，一行代码不想改，又希望能使用微服务的高级治理能力，如灰度发布、限流降级等等，这时候通过这种非侵入的技术就能迎刃而解了。

另外，再补充一点关于微服务SDK与Service Mesh技术之争，目前业界有些声音认为Service Mesh是下一代微服务技术，会替代SDK模式。

从当前实际的业务诉求来看，这两者在微服务功能上确实有些重合，例如在微服务的路由管控、遥测和安全这些方面的能力，两种方式都可以实现，但SDK本身还有另外一个职责，就是标准化微服务的团队交付方式。例如：

• 标准化了微服务的打包方式（软件包定义、编译设置、依赖管理）；

• 标准化了微服务的发布方式（服务定义、如何注册配置监控、通信协议、安全认证等等）；

• 标准化了微服务接口的定义方式（数据模型定义、操作模型定义）；

• 标准化了微服务公共能力的开发方式（动态配置、日志记录、监控埋点、事务协调、文件存储、数据库/缓存/消息中间件访问）。

标准化的目标是为了规范化和自动化，而这两者是提高团队研发效率的基本手段。当然，一个作坊式软件开发团队，人数少，业务规模小，管理没那么复杂，随便怎么干影响也不大。但是，当你的研发团队增长到近百人，甚至上千规模时，标准化的开发方式是支撑团队高效工作的基本要求。

华为微服务流水线解决方案

微服务的交付过程跟以前其实没什么区别，都是从coding、编译、打包、测试、部署到上线这些基本的交付活动，但是微服务模式下却比以前更加需要流水线这么一个自动化的工具平台来支撑，主要是微服务的数量太多了（动辄几十上百），交付活动中的任何一个环节无法自动化就会对整个业务上线效率造成很大的影响，很容易导致业务微服务化之后不仅没快起来，反而比以前更慢。别小看这一点，我们所经历过的大部分微服务转型项目都掉过这个坑。

大家都知道，提升效率的最好办法就是尽可能自动化，而能自动化的前提是先把业务或者活动进行建模并标准化，微服务流水线看上去是一套工具平台，本质上是对团队开发活动中各个环节进行了一系列标准化，从微服务编写第一行代码开始，包括微服务的开发方式，如微服务的定义、接口的定义、周边依赖集成方式等；也包括微服务的交付过程活动，如编译、打包、测试和部署模板、脚本和环境配置都进行了标准化。这样能让开发人员聚焦业务本身逻辑的开发，以及简化团队之间的协作，最终实现整体交付效率的提升。

华为微服务灰度发布解决方案

在互联网行业，特别是一些业务创新场景都强调要快速试错，很多面向消费者的优秀应用并不是从一开始就设计好的，而是通过不断的快速迭代、快速试错，逐步进化而来的。

我们理解快速试错其实包含两种场景：

• 其一，不得不承认无论怎么加强测试，因为各种因素（例如环境差异、场景差异、人的差异等等）是软件都会有一些bug成为漏网之鱼，如果无法避免这些bug，那我们希望当这些bug出现时尽可能影响最小化；

• 其二，我们会很高频率的上线一些小的特性，这些特性有的来自于部分客户的需求，有的来自于行业洞察，有的来自于愿景规划，但这些新的特性是不是所有用户都喜欢的，或者还有哪些改进点，我们希望这个发布过程能管控起来，灰度发布就是一个很好的解决途径，我们可以通过对新版本的发布范围、使用对象、甚至使用场景进行细粒度控制，这样就能最大化降低发布风险。

当然，灰度发布的适用场景并不局限于此。

曾经遇到过有个客户的应用场景挺有意思，他们运营着一个物业电梯管理的SaaS应用，发现每个客户对都有些不同程度的定制诉求，一开始没想太多反正定制工作量也不大，就为每个客户定制一个版本然后各自部署一套，张三就访问张三的那一套，李四就访问李四的那一套，相安无事挺好。

可是后来他们发现这样搞资源太浪费了，因为这些系统其实90%以上的功能都一样，而各自部署的服务器资源利用率都很低，于是后来他们做了一件事，把面向不同客户的定制部分抽出来做成独立的微服务，然后通过配置灰度规则，让不同用户访问到各自定制版微服务上，通用功能只部署一套，这样就大大节省了资源，而且还减少了维护工作量。

华为微服务治理解决方案

在微服务系统上线之后，我们要尽可能的做到运维的自动驾驶，因为靠传统那种手拉肩扛的运维方式是不可能运维好复杂的微服务系统的，这里更大的挑战是这种自动运维的场景对微服务运行时各种指标的监控和及时响应都提出了非常高的要求。

微服务的治理措施有很多，例如负载均衡、黑白名单、服务限流/降级/容错/熔断、故障预测/自愈等等，我们可以根据实际的应用场景选择相应的治理措施。

负载均衡

这不是一个新技术，但这里重点说一下在微服务系统里负载均衡的应用方式有什么不同，传统的应用架构一般是分层的。例如从外到里有接入层、展示层、业务逻辑层、持久化层，我们一般在系统的最外层加一个F5或Nginx作为负载均衡器，来确保入口处的流量被均匀地分配到后端的处理服务上。但是在微服务系统里，由于服务粒度小了很多之后，整个架构并没有明确的层次之分，更多的像个网状结构，如下图：

每个微服务都可能多实例部署，这时候每个微服务之间的访问也需要负载均衡，如果用传统的方式在每个微服务之间加一个F5或者Nginx，这是不可能的。首先成本就受不了，所以需要从微服务框架就要支持这种能力。

负载均衡的策略可以有多种。

• 轮询、随机、会话粘滞：如果用户请求第一次访问了某个实例，则后续该用户的所有请求都访问这个实例；

• 实例负载：根据当前所有实例的负载，例如CPU使用率来判断闲或者忙，再来决策路由到合适的实例；

• 响应权值：根据所有实例历史处理请求的响应延时情况，来选择满足SLA的实例。

容错熔断

任何微服务之间的任何一次调用都有可能会失败，但我们的系统又必须做到更好的SLA，这就要求架构师在微服务的设计之初就要考虑到各种失败场景和应对措施。当然，如果把这种工作都交给业务开发人员来处理，门槛会非常高。

好在我们已经在微服务框架里内置了一些容错能力，例如调用一个实例失败了可以尝试重试几次，也可以选择路由到另一个正常的实例，当所有实例都失败可以启用自定义的预案措施，同时对于后续的调用可以快速失败返回，以防止交通堵塞。

熔断的场景就类似于我们家里用于电路上的保险丝，当发现某个微服务的负载较大时，系统会自动把通向该服务的流量掐掉，直到监测到负载正常时再恢复。

限流降级

任何微服务的容量（处理的最大请求量）都不是无限的，所以要进行限流的治理，以保证微服务不被无论正常还是恶意的流量搞垮。

另外一个场景，我们可以根据请求方的消费级别（例如铂金用户、黄金用户、普通用户等）来分配不同的流量限制，以实现差异化的商业服务。

降级主要应用在两种场景：

• 有些时候当系统中的某些服务挂掉了，为了防止故障蔓延，可以降级掉对故障服务的调用，以保证系统的其他功能还能用，例如不可能因为商品广告服务出故障而导致整个电商网页打不开，可以把广告服务降级，让用户至少可以打开首页浏览商品；

• 在一些资源受限的场景，可以主动降级掉系统中一些非关键服务来保证核心服务的资源诉求，例如在电商促销活动之前，可以把非关键的日志服务、评论服务或者推荐服务等等通过降级的方式先关掉，把资源调配给核心的商品列表、下单、支付等服务。

黑白名单

我们有很多企业客户为了在内部实现数据共享和能力共用，来提升公司运作效率，会把一些内部企业支撑系统通过微服务的方式发布出来，但是有些数据会比较敏感不适合在太大的范围公开，因此对处理这一类数据的微服务自然而然就有了安全管控的要求，通过黑白名单管理就可以很方便的控制微服务的访问范围。

还有很多有用的治理手段，这里就不一一列举，有效的治理措施取决于对微服务系统运行状态精确的监控，我们需要做到对微服务360度监控，例如：微服务所在集群和节点的CPU、内存、磁盘和网络等资源指标的监控，微服务本身的吞吐量、时延和错误率等应用指标的监控，以及微服务所依赖的数据库、缓存、消息、网关等中间件指标的监控，跟寻医问诊一样，只有对病情有足够的诊断，才能开出最合适的药方。

华为微服务开源进展和路标

2017年6月，在由 Linux Foundation 主办的 LinuxCon + ContainerCon +CloudOpen（LC3）开源峰会上，华为宣布开源微服务框架 ServiceComb，开源后的ServiceComb将帮助广大开发者快速开发云原生应用，共同推进构建行业云生态。

又于同年11月，开源社区 Apache 软件基金会孵化器项目管理委员会 ASF IPMC 宣布华为云开源的 ServiceComb 项目全票通过进入 Apache 孵化器。这也是华为继 CarbonData 之后，第二个进入 Apache 孵化的开源项目。

进入 Apache 孵化器，也意味着 ServiceComb 社区将遵循Apache Way,社区将更加开放、中立及多样化，也欢迎更多的厂商及个人开发者参与社区。

华为开放微服务框架的逻辑也很简单：

其一，这确实是一个经过内部广泛实践验证过的好东西，捐献出来希望能进一步促进行业更快的向微服务转型；

其二，微服务的生态很大，华为不可能也没有能力涉猎各行各业，所以希望抛砖引玉，联合大家一起完善生态；

其三，微服务框架是业务开发的基础组件，全部开源出来也可以打消很多华为客户担心被技术绑定的疑虑，华为提供的微服务相关商业产品也都是基于这套开源版本构建的。