背景分析

微服务带来的协同问题

微服务软件架构（microservices）已经被越来越多的企业作为规模分布式软件开发的首选架构。引入该架构之初是将一个单体应用拆解成多个更小粒度的微服务(micro-service)，通过HTTP API或像Dubbo这样的RPC框架将这些服务组装起来作为整体去提供服务。由于每个微服务足够地小且功能内聚，因此能很好地解决以往单体应用的开发与发布困难的问题。即便如此，随着企业的业务发展和人员规模的壮大，不同业务所形成的微服务群之间的协同却面临新的挑战。

• 服务调用的富客户端版本升级：RPC框架由基础架构组统一开发与维护，以SDK形式提供给其他部门使用。由于SDK与应用逻辑是耦合在同一个进程中的，当SDK向前演进所增加的特性并不是某些业务方所需要的时，这些业务方就没有动力配合中间件事业部去同步升级自己应用中的SDK版本，使得SDK在整个集团存在多个版本甚至变成长尾而形成包袱。类似的包袱反过来制约了RPC框架自身的演进效率。SDK中lib库的升级无法对业务系统做到完全透明：业务系统会因为和业务无关的lib库升级而不得不进行升级。

• 多编程语言支持：分布式架构技术的火热，使得一些额外的分布式能力比如：如负载均衡、熔断限流、链路监控等也开始集成到SDK中。带来的好处是屏蔽了底层的实现细节，但是却使得应用程序的依赖变得越来越臃肿且难以维护。并且一些主流的微服务框架通常都与某种特定开发语言进行绑定，这就很难做到语言无关。当微服务框架是单一编程语言独大、不能同步支持好其他多个主流编程语言时（比如C++、Go、Node.js等）,就会出现非独大编程语言的SDK在特性上严重滞后于独大编程语言的，最终影响使用非独大编程语言的业务方以自己最为熟悉的编程语言去发展和探索业务。编程语言独大所带来的好处是多数人的技术栈是一样的而提高了技术层面的协作效率，但却无法收获编程语言多样性所带来的其他好处。即便同步地对多个编程语言的SDK进行维护，同样的特性需要用不同的编程语言去实现其成本着实很高。

• 在微服务软件架构所主张的拆分手法下，确实可以将每个拆分出来的服务从监管控层面做到足够的精致，但这势必会因为概念抽象不同、团队成熟度不一致等原因而使得这些“精致的烟囱”难以高效无缝协同，最终的结果是软件功能的易用性、风险的可控性和适应业务变化的敏捷性无法做到全局最优。