作者 | 李林锋

创新互联公司是一家集网站建设,杂多企业网站建设,杂多品牌网站建设,网站定制,杂多网站建设报价,网络营销,网络优化,杂多网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。

《Netty 进阶之路》、《分布式服务框架原理与实践》作者李林锋分享大规模业务团队实施微服务的经验和教训。

引言——背景

对于一些复杂的业务系统(例如CRM)进行服务化改造，涉及到多个业务团队的配合和协调，加上业务本身的复杂度，对已有的系统进行微服务化重构是个极具挑战的任务...

实施前的准备工作——目标要清晰，处理好“舍与得”

教训
1、微服务化目标不清晰：

各业务模块处在不同技术阶段，有单体应用、RPC架构、SOA服务等，业务痛点不同。没有明确各业务的微服务化目标：是提升开发效率、缩短新业务上线周期，还是单纯的追求技术先进性。

2、没有处理好“舍与得”：

微服务不是银弹，看着美好，但是要在大规模团队和电信复杂业务系统中实施，一定要处理好舍与得。例如分布式带来的时延增加、可靠性降低。

经验总结
明确目标，敢于舍弃

实施前的准备工作——微服务不仅仅是架构师的愿景

教训
1、愿景美好，但落地变形：

顶层架构设计仅仅存在于架构师的脑海和架构设计文档中，设计理念和关键架构属性，底层的开发人员并不完全理解，架构落地时存在较大偏差。

2、大兵团作战，各自为战：

大规模业务团队拆分成很多小的微服务团队之后，需要互相协作和配合，在架构设计原则的理解和遵循上存在较大偏差，各自为战。

经验总结
统一认识，组织赋能

实施前的准备工作——技术选型要全面

教训
1、过于关注运行态服务框架，而忽略其它质量属性：

在选型时，过于关注微服务框架的性能指标、功能丰富性，以及对业务的侵入程度，而忽略了服务运维和治理。

2、忽略微服务语言中立原则：

业务模块多，场景复杂。大部分业务采用Java开发，但是对于计费、批价等性能要求苛刻的业务仍然需要继续使用C（C++）、GO等语言，服务框架不支持异构语言，跨语言调用存在问题。

经验总结
分析全面，语言中立

跨团队协作——接口依赖和进度协同问题多

教训
1、无法及时提供接口API，影响其它团队开发进度：

a) 初期经验不足：服务提供者过分专注于微服务的内部实现，而不是优先设计微服务的API提供契约化的接口给消费者。

b) 后期项目规则制约：限制迭代微服务接口变更次数。 提供者担心接口会经常性的变更和重构，迟迟不提供接口契约。

2、无有效的变更通知机制：

微服务接口契约文档离线管理，变更之后无有效通知机制。

经验总结
推行API First设计理念

01 消费者参与：

推行API First的设计理念，让微服务提供者从消费者的角度，与消费者一起设计API，同时把API通过在线的方式发布和管控起来。

02 全在线：

基于swagger，可以通过YAML或者JSON的方式设计API、在线发布API。

跨团队协作——接口兼容性问题

教训
1、微服务版本管控意识不强，随意变更：

随意删除、修改接口字段，导致其它团队CI构建失败，测试用例通过率低。

2、完全基于管理手段：

通过管理条例等约束接口变更，但是缺乏统一的技术保障手段。例如新增字段、删除字段，不同语言、不同团队怎么保证实施的一致性。

经验总结
技术保障、管理协同

01

制定并严格执行《微服务接口兼容性规范》，避免发生不兼容修改或者私自修改不通知周边的情况。

02

接口兼容性技术保障：例如Thrift的IDL，支持新增、修改和删除字段，字段定义位置无关性，码流支持乱序等。通过URL中携带V1/V2等主版本号，实现灰度路由。

03

持续交付流水线的每日构建和契约化驱动测试，能够快速识别和发现不兼容。

微服务实施——不是所有业务都一刀切

教训
1、研发阶段：

为了技术架构的统一，不考虑业务之间的差异性，不同业务的痛点差异，全部一刀切的进行微服务化改造。

2、上线阶段：

一次性全量上线，所有微服务化改造的业务同时进行升级，没有观察期和缓冲期。

经验总结
循序渐进、稳扎稳打

01 先外围，后中心：

先找一些相对成熟，非核心模块的业务做微服务改造，在这个过程中不断积累经验，为后续核心模块的微服务化做准备。

02 麻雀虽小五脏俱全：

在微服务化早期实践中，除了开发工具和运行框架，需要把微服务持续交付流水线、微服务治理框架、调用链分析等配套设施全部构建起来。

03 逐步上线和上量：

上线时，可以采用灰度路由等方式，逐步把流量切换到新的微服务系统中来。

不可忽视的技术细节——微服务编排

教训
1、编排框架混乱：

硬编码/BPMN流程引擎、脚本（Groovy、JS）编排引擎等，缺乏统一的轻量级微服务编排引擎（PVM）。

2、微服务编排层：

顶层缺乏统一的设计和策略，导致各业务模块实现五花八门。有的在后台能力中心层、有的在中台、有的在API Gateway、有的在客户端。

经验总结
轻量级微服务编排层

01

按需选择轻量级的微服务编排引擎（PVM）， 传统的BPMN在微服务时代模型较重、依赖较多。

02

微服务的编排适合单独独立出来（中台），保障后台微服务的原子性、稳定性，同时又能够满足前台、移动端各种个性化需求。

不可忽视的技术细节——分布式事务

教训
1、分布式事务选型：

业务补偿、事务强一致性（TCC框架）或者基于消息的最终一致性方案，平台和业务之间、不同业务团队之间没有达成一致性方案，影响事务一致性。

2、习惯思维，强一致性事务占比过高：

单体应用都是本地事务，强一致性容易保障。服务化之后，没有基于业务场景深入分析，习惯性的采用强一致性方案，业务成本很高。

经验总结
以用户体验为本，兼顾时效性与成本

01

最终一致性，采用基于消息中间件的事务方案。

02

强一致性，TCC方案。

不可忽视的技术细节——API开放和集成

教训
1、内部的实现细节开放给前端/第三方：

包括但不限于特定语言的实现细节，例如异常类、继承和重载、抽象接口等。

2、为了后端数据结构重用，开放冗余的字段：

有时候为了重用内部的数据结构，把整个对象都开放出去，事实上消费者只需要使用其中的几个字段，导致接口易用性变差。

3、缺乏统一的 API Gateway：

没有统一的API入口和精准的流量管控手段。

经验总结
基于API Gateway，提升开放API的易用性

不可忽视的技术细节——熔断和降级

教训
1、闭门造车，技术五花八门：

没有构建统一的微服务可靠性框架、故障注入框架等，不同的业务团队各自为战。经验丰富的团队，可靠性做的较好，技能较差的团队，缺乏有效的可靠性保障。

2、重复研发，资源浪费：

业务场景不同，可靠性诉求大同小异。异步数据库访问、异步I/O操作、微服务故障隔离等能力，被不同团队重复构建。

经验总结
集成业界成熟技术，统一构建可靠性和故障注入框架

对第三方依赖进行分类、分组管理，根据依赖的特点设置熔断策略、优雅降级策略、超时策略等，以实现差异化的处理。

体系化的故障场景梳理——微服务故障隔离全景图

教训
1、没有体系化的梳理微服务故障场景。

2、没有自动化的微服务故障注入和模拟工具，微服务可靠性测试场景覆盖不足，问题遗留到线上。

经验总结
体系化的故障场景分析、自动化故障注入和故障隔离措施，提升微服务的可靠性

不可忽视的技术细节——微服务是否必须独立部署

教训
1、机械照搬微服务原则，所有微服务都独立部署：

上千个微服务，上百个节点集群组网，微服务进程数膨胀到数十万，周边配套设施无法承受（例如网管OSS）。

2、为了简化部署和管理，微服务全部合设在同一个进程：

丧失升级灵活性、无法按需伸缩、故障隔离差、异构语言无法合设在一起等缺点。

经验总结
按照微服务的拆分粒度、微服务规模、以及运维团队能够接受的维护成本来决定微服务的部署策略

01

可以进程内合设的微服务

a) 性能、时延要求苛刻，需要本地短路的微服务可以合设。

b) 业务强相关的一组微服务，为了便于统一管理。

c) 暂时不支持分布式事务，需要本地事务保障强一致性的相关微服务（非长久之计）。

02

拆分粒度较粗的微服务、功能独立和内聚，建议独立部署。

不可忽视的技术细节——告警泛滥，坐卧不安

教训
1、告警漫天飞，心惊肉跳：

微服务化之后，本地的方法调用变成了远程的微服务调用，一个业务流程的多个微服务会有多个开发者负责。告警也由本地集中式演变成了分散的分布式告警，如果仍然沿用之前的告警方式，就会发现告警满天飞，而且大部分告警都是重复无效的告警。

经验总结
动态构造告警树，自动抑制重复告警

01 原理

结合分布式调用链跟踪功能，在运行态将微服务调用关系动态刻画出来，然后构造告警树，每次叶子节点发生异常需要告警时，需要沿着树干层层下钻，对告警进行关联，寻找告警的Root节点，如果能够匹配上，则说明已经由根节点做了告警，叶子节点放弃告警，防止重复告警。

平台和业务关系——并非甲方和乙方

教训
1、以甲乙方来处理微服务平台和业务的关系：

大规模业务团队，服务化需求五花八门，平台方需要识别高优先级、通用的需求，大部分个性化的需求需要开放给业务团队实现，或者规划到后续版本。如果业务方只从本团队利益出发，不顾全大局，很容易压垮平台，最终交付质量无法保障。

经验总结
敢于和善于拒绝不合理需求

01 平台方：

a) 合理沟通，据理力争。

b) 深刻理解业务场景，抓主要矛盾和矛盾的主要方面。

c) 敢于承担责任，敢于对不合理需求说“不”。

02 业务方：

a) 不断提升微服务实践经验，能够分辨哪些是平台需求，哪些是业务需求。

b) 与平台建立互信、合作共赢的新型关系。

关注微服务技术，关注云原生，就在“微服务蜂巢”公众号

网站标题：大规模微服务实战经验
路径分享：http://ybzwz.com/article/jodhsh.html