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

未来已来2019-01-04 15:30

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


事实并非如此。


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


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


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


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

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

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

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

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


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


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


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


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