微服务架构风格可以降低系统的复杂度吗？

有人说：使用多个独立的微服务组合成一个复杂的业务系统。如此的话，业务系统整体的复杂度并没有降低。如果极限情况下，每个public函数都是一个独立运行的服务，如此一来反倒是增加系统的复杂度。如此看来，微服务只不过是解决了部分功能的扩展性的问题。和SOA架构或者monolic相比，并没有根本性的改变。

事实并非如此。

分布式意味着复杂性的挑战，以静止的观点来看，也就是系统长期没什么大变化这种情况，采用微服务架构通常会增加系统整体的复杂度，得不偿失。

然而有个词叫做“架构腐化”，系统不可能静止不动，随着业务的成长，市场的变化，系统总要不断增加新的能力，时间长了，最初简单高效的架构，往往就会变得极其复杂，臃肿不堪，即便最初的规范、分层都合理了，可扩展性、可用性、性能带来的复杂性也是难以避免的，祖传代码牵一发而动全身，改一行修半年该有多可怕。这也是熵增原理的一种体现。

而采用微服务架构，边界和职责明确了，模块高内聚低耦合，系统熵增就可以变慢，而且系统分拆之后，对于负责单个微服务的小团队来说，工作也变得很简单多了。这都是强调服务总线（ESB）的 SOA 和单体架构所不能的。

诚然微服务架构的正常运转需要做很多事情，比如：

• 服务注册/发现：服务实例的网络地址是动态分配的，服务实例的配置也经常变化，没有这个就不好玩了。

• 持续部署：功能越多，构建和部署时间越多，再小的修改都需要部署，要是手动部署的话，这人生就看到头了。

• 异常定位与修复：服务众多链路复杂的时候，这和在茫茫人海中找到那个他/她有一拼了。

• 高可用：服务之间确实相对独立，资源也隔离，减少局部故障对整体的影响，但是有调用和依赖，不做好每一个服务的高可用，就要等着雪崩了。

但这些是基础设施层面的工作，只要有一个好的微服务基础设施，业务侵入性很小，尽可能支持自动化，就不是问题了。网易云轻舟微服务的设计，就是希望解决微服务应用生命周期的一切问题。

所以，微服务架构也不仅仅解决部分功能扩展性的问题，对于系统可用性的保证，沟通成本的减少，支持技术选择的多样性，到研发效率的提升，微服务可以发挥的作用还是非常巨大的。

优化业务系统的复杂度，应该在于保证业务响应能力、业务创新能力，同时提升 IT 效率，很多互联网公司以及传统企业都在搞微服务，当然是因为搞微服务是有这种好处的。

相关文章：
【推荐】 消息推送平台高可用实践（上）
【推荐】 改进网易云音乐的“音乐社交”构想