大规模微服务实战经验

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

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

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

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

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

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

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

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

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

2、完全基于管理手段：

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

2、上线阶段：

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

2、微服务编排层：

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

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

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

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

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

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

3、缺乏统一的 API Gateway：

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

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

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

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

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

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

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

动态构造告警树，自动抑制重复告警

李林锋

10 年 Java NIO、平台中间件设计和开发经验，精通 Netty、Mina、分布式服务框架、API Gateway、PaaS 等,《Netty 进阶之路》、《分布式服务框架原理与实践》作者。目前在华为终端应用市场负责业务微服务化、云化、全球化等相关设计和开发工作。

联系方式：

新浪微博：Nettying

微信：Nettying

Email：neu_lilinfeng@sina.com

年前送一波福利~

关注公众号 + 评论

点赞前三 送 李老师的 《Netty 进阶之路》 哦~

在这个寒冷的时节里

因为有你的关注

而变得温暖