以下文章来源于码猿外 ,作者麻广广
记录码外的思考
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
为了更好的解决特殊场景的问题,微服务架构并不提倡使用适合所有场景的标准化技术,而是针对每个服务的特点,选择更合适的技术。这个技术不仅包括编程语言、技术框架,当然也包括数据存储技术;纽曼(Sam Newman)在《微服务设计》一书中举了一个例子很好的解释了数据存储技术异构带来的好处:对于社交网络来说,图数据库能够更好的处理用户之间的交互操作,但对于用户发布的帖子而言,文档数据库可能是一个更好的选择
微服务是小而自治的,自治性的一个非常重要的特性就是独立部署,一个服务的修改和部署不应该对其他服务产生影响,但如果多个服务共享数据库,在数据库层的耦合让不确定性变大,一个服务对数据库结构的变更很有可能影响其他服务,即破坏了自治性。自治性的好处体现在整个系统的弹性上,当一个服务发生故障时,不会造成整个系统的不可用。然而,如果多个服务共享数据库,数据库的异常会导致多个服务同时故障,也就大大增加了整个系统不可用的概率。自治性还体现在服务的可扩展性上,不同的服务因业务不同其需要满足的性能和并发量要求也不同。当请求量增加时只需要对部分服务进行扩展,而不是所有服务;同样当数据库性能无法满足需求时,只需要对部分服务的数据库进行扩容升级,而如果多个服务共享数据库,扩容升级的影响就会作用到多个服务,一方面破坏了服务的自治性,另一方面当其他服务对数据库没有那么高要求时,资源是浪费的。继续杠精附体,那是不是可以把并发量和性能要求相近的业务合并为一个服务,而共享同一个数据库呢?
这个问题其实是微服务架构实施落地的一个非常热点问题:如何划分微服务?划分微服务要遵循高内聚、低耦合这个原则的,这也是微服务架构优势所在;《领域驱动设计》引入了限界上下文(bounded context)的概念,通过对业务的梳理找到不同业务上下文之间的边界,帮助我们找到了划分微服务的方法,这里的重点在业务边界。James Lewis和Martin Fowler在微服务的定义中也强调微服务是构建在业务能力之上的,可见微服务的小而自治是建立在独立的业务能力基础之上的。因此,简单的将并发量和性能要求相近的业务合并到一个服务中,无法达到微服务期望的效果,也就没法获得微服务所具有的好处。一方面不同的业务对数据库的要求除了要考虑并发量和性能,还应该包括数据量的大小、读写的比例、实时性要求等等,共享数据库的方式一般情况下也很难满足不同业务服务对这些指标的要求,将所有服务的数据都存放在一个数据库中本身也是一种非常大的挑战。另一方面用动态的视角看这个问题,业务是发展的,随着市场的不断变化,不同的业务随时间而演进出来的需求可能是完全不同的,对数据库的需求也会有所不同,共享数据库的方式很可能变成瓶颈限制业务的发展。
微服务架构风格还有一个非常重要的特征,就是支持架构的演进;不论是互联网企业,还是在数字化转型过程中的传统企业,市场的变化和不确定性是不可避免的,当接到一个新的需求,如果需要用新的技术手段来解决,微服务架构就体现出了独特的优势,在不对其他服务产生影响的情况下,可以随意变更一个服务内部的技术框架或数据存储技术,共享数据库明显做不到这一点。
*参考资料:
James Lewis、Martin Fowler《Microservices》
- 扫描下方二维码,观看相关直播回放 -
- 相关阅读 -