微服务架构是一颗银弹吗？

如今微服务架构正逐渐演变成一种主流的架构风格，那么微服务架构是一颗银弹吗？我们提倡微服务架构的目的是什么？

1987 IBM大型机之父Fred Brooks在《没有银弹：软件工程的本质性与附属性工作》中提出软件工程包括本质性工作和附属性工作。本质性工作是创造出一种由抽象的软件实体所组成的复杂概念结构；附属性工作是用程序语言来表达抽象概念，并在空间和时间的限制下，翻译成机器语言。《没有银弹》主张并断言在未来的十年之内（从1986年文章发表后开始计算），不会有任何单一软件工程上的突破，能够让程序开发的生产力得到一个数量级(10倍)的提升。我们讨论或推广一项软件实践或技术的时候，实际上是在谈如何提高生产力。本文试图利用《没有银弹》对本质性工作四个原因的归类，去认识微服务架构的生产力。《没有银弹》认为本质性工作大部分的活动是发生在人们的脑海里，具有四大难题：复杂性、隐匿性、配合性和易变性。

软件要解决的问题通常牵扯到多种元素和计算步骤，这是一种人为的、抽象的智能活动，多半是复杂的。随着“软件吞噬世界”不断深入，软件所对应的社会活动越来越多，也越来越复杂。

系统往往是承载的业务越成功，越容易失败。因为系统会随着业务的发展，增加越来越多的特性和功能，使得系统复杂到没有一个人能全面理解，没有一个人敢去修改原有的功能或代码。

微服务提出以业务边界作为模块划分原则，每个模块独立进程。一个业务由很多独立的小业务组合而成，系统也是由独立的小系统组合而成，这样的好处是每个小系统都很容易被理解，一个大系统可以根据业务组合微服务，或者逐渐发展独立的微服务。

但是微服务架构真的降低了系统的复杂性吗？ 其实并没有， 而且是增加了系统的总体复杂性！微服务之间的连接更加复杂，网络通讯不可靠和性能损耗，协议匹配，接口对接和转换，版本协作，微服务注册和发现，编排和调度，分布式业务和数据一致性等等复杂性都是单体架构不需要考虑的。微服务为了降低单个微服务的复杂性，导致整体系统的复杂性急剧增加。如果单体架构根据业务进行模块划分，每个模块之间根据宿主语言接口进行交互，就像OSGi那样模块化/插件架构完全可以做到模块化开发。

那么为了降低系统复杂性，是不是放弃使用微服务？ 答案既是肯定也是否定。我们刚才发现微服务架构带来的复杂性，大多是附属性问题。对于本质性复杂性，微服务使用上下文界限实践，可以更好的隔离依赖业务概念的复杂性，从而降低单个微服务的复杂性。

既然有得有失，我们是否需要做个权衡？《没有银弹》的主张只说对了一半，10年内对于本质性问题确实是不会有十倍生产力的提高。但历史上来看，附属性问题是有十倍生产力提高的。 而我们在软件工程实践中，往往本质性问题和附属行问题混合在一起，我们需要不断的加深认识，区分两者，并相互改进。微服务架构带来的附属性复杂性必须要有一个功能齐全的PaaS进行转移。微服务推广初期(包括现在)所面临的很多问题，其实是缺乏一个功能齐全的PaaS，比如AWS/Azue,Rancher/OpenShrift，用以解决附属性问题。所以我们不需要做太多的利弊权衡，因为PaaS日趋成熟，成本将降到几乎可以忽略不计。微服务架构利用PaaS对附属性问题的转移，降低一点点本质性问题的复杂性，也是非常价值的。只是发挥这种价值，需要掌握DDD设计实践，利用好上下文界限来降低单个微服务的本质性复杂性。

软件在没有应用到业务之前，各种信息和思考大多在每个人的脑海里，很难完全呈现和想象出来。客户只是模糊的知道自己想要什么，但并不知道要怎样的软件；项目经理有把握软件开发进度的能力，但不知道软件每个阶段后能长成什么样；业务分析员能把业务分析清楚但不能确认转变成最终软件会成为什么样；开发设计人员知道怎么做软件，但又不能完全理解业务需求。