观点：逃离单体系统，拥抱微服务？
极客时间编辑部
讲述：子阳大小：2.33M时长：05:06
微服务架构现在已经成为了企业应用架构的必聊话题，其中一个主流观点是逃离单体系统，拥抱微服务，对此，《高可用可伸缩微服务架构》一书的联合作者梁桂钊结合自己多年工作的所见所闻和实战思考，谈了谈他的观点，以下为具体内容。
单体系统和微服务的区别在于，一个单体系统是一个大而全的功能集合，每个服务器运行的是这个应用的完整服务。而微服务是独立自治的功能模块，它是生态系统中的一部分，和其他微服务是共生关系。
现在，业界对单体系统和微服务的普遍观点是：单体系统非常容易开发、测试、部署，但是单体系统面对的问题也很多，例如开发效率变低、维护成本增加、部署影响变大、可扩展性较差、技术选型成本高等等，而引入了微服务可以实现每个微服务易于开发与维护，便于沟通与协作，很适合小团队敏捷开发与持续交付。
微服务的优势主要有以下几点：
每个微服务职责单一，高内聚、低耦合；
每个微服务都能够独立开发、独立运行、独立部署，如果某个服务部署或者宕机，只会影响到当前服务，而不会对整个业务系统产生影响；
每个微服务可以随着系统规模的不断扩大，面对海量用户和高并发，独立做水平扩展与垂直扩展；
每个微服务可以使用不同的编程语言以及不同的存储技术，使得我们更容易尝试新的技术。此外，对单个服务进行业务重构，也不会面临很大的业务负担与技术债券。
我对微服务系统的观点是，我们从单体系统向微服务系统改造的过程中，需要认真思考什么阶段使用微服务。微服务不是银弹，它对于设计和运维难度提出了更高的要求，同时也带来了一些技术的复杂度。
因此，我们需要思考与解决分布式的复杂性、数据的一致性、服务的管理与运维、服务的自动化部署等解决方案。事实上，微服务通过拆分单体系统使其成为多个体积更小的服务来降低单个服务的复杂性，但是，我们从整体来看，这种方式造成了大量服务的存在，而服务之间的相互调用也会增多，从而导致整个系统架构变得更加复杂。
我们经常忽视业务价值和成本考量，而太过追求技术，那么可能会导致我们精心设计的分布式架构严重影响我们开发的速度和业务的快速迭代，并且随着业务的不确定性往往导致我们的架构在半年到一年之内就已经不完全适用，推倒重来。
此外，如果业务没有发展起来也会导致前期大量的服务器资源盲目的浪费了，这对于初创业务得不偿失。因此，我们在项目前期为了保证快速增长业务，保证系统尽量减少依赖且独立完整，减低引入微服务架构后的技术复杂度，例如它对于运维难度提出了更高的要求，因为好的微服务架构需要稳定的基础设施。
随着业务发展良好，系统规模会不断扩大，它的扩展性、伸缩性、可用性和性能都限制了我们的业务发展，此时，我们怀着明确的业务思考和投入更多的资源再来考虑微服务改造。
微服务架构使用服务作为模块化的单元，那么，我们可以在前期设计的时候通过 Maven 的 module 模块化来初步隔离依赖，为我们之后的改造预留空间。注意的是，微服务在生态系统中是共生关系。这里，不仅仅局限在它们可能存在链路依赖，同时它们的业务价值一定是共生的。因此，后期识别出单体系统的核心价值、关键功能，再把这些功能拆分成独立且自完整的模块。这里，改造方案可以阅读《高可用可伸缩微服务架构》一书的第十二章 “遗留系统的微服务架构改造”。
总结一下，微服务通过拆分单体系统使其成为多个体积更小的服务来降低单个服务的复杂性，但是，我们从整体来看，这种方式造成了大量服务的存在，而服务之间的相互调用也会增多，从而导致整个系统架构变得更加复杂。因此，我们不单单只关注技术，而需要考量投入产出比，保障当前阶段的利益最大化。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论