【干货分享】基于微服务架构的爱恨情仇

easthomeRT

本文来自“”微服务不是免费的午餐”文章的摘录。

当今市场瞬息万变，软件为了适应动态市场的需要就需要增加产品发布的频率，有时会是一天发布多次。另外，随着软件产品的同质化竞争，终端用户对应用的易用性要求越来越高，对任何宕机采取零容忍的态度。当下基于云服务能力，软件的可扩展性和高可用性的需求也变成了一种常态需求，微服务的概念和应用实践更被推到了软件部署的风口浪尖。

所谓微服务就是一种架构模式，我们可以把它作为传统基于面向服务架构（SOA）的一种变体。微服务提倡将单一应用程序划分成一组小的服务，而服务之间可以互相协调和互相配合，共同为终端用户提供必要的产品使用价值。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP 的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境和类生产环境等。对具体的一个服务而言，应根据系统上下文，选择合适的语言和工具对其进行构建。

微服务架构是相对于传统开发的单体式架构（Monolithic Architecture）而言的。单体式架构也称巨石型架构，是所有功能或组件都打包在一起进行发布，此发布包通常包含数据输入/输出、数据处理、业务实现、错误处理、前端显示等所有逻辑。

这样的发布方式就很少有外部软件的依赖，说明单体式架构也是有优点的，比如开发团队的组织架构简单，便于集中式管理，避免重复开发的问题。并且，所有功能都集中在本地，不存在分布式的管理和调用损耗。但是这个架构的缺点也是很明显的，比如开发人员更新代码会受到彼此限制，经常需要相互等待对方的功能更新，代码入库时的冲突不断，造成极高的开发成本。另外，维护难，各个模块的代码都耦合在一起，没有经验的新人不知道从何下手，而一旦出现软件Bug，就需要大改。并且构建（Build）时间过长，任何一个小量级的修改，都要重构整个项目，编译非常耗时。还有一个缺点就是稳定性差，一个微小的问题，都可能导致整个进程崩溃，使得整个应用程序无法工作。扩展性不够也是一个缺点，难以分布式部署和扩容，无法满足高并发下的业务需求。而且，一旦业务范围扩展或者需求有所变化，就难以复用原有的服务，必须重新开发。

单体式架构一般适用于企业刚起步时，业务规模小，开发团队规模也小，所以通常开发出来的系统是单块的。随着业务的扩大，团队规模也会随之扩大，这个时候多团队组织架构和单块系统架构之间就会产生不匹配问题（沟通协调成本增加，交付效率低下等等）。如果不对单块架构进行解耦和调整以适应新的团队沟通结构，就会制约组织生产力和创新速度。把单块架构按照业务和团队边界进行拆分，重新调整为模块化分散式架构（微服务架构是一种方案），那么组织团队沟通结构和系统架构之间又能匹配起来，各个团队才能够独立自治地演化各自的子系统（微服务），这种架构的解耦和调整可以解放组织生产力和提升创新速度。

微服务架构的优点和缺点都很明显。

优点是：1、部署、回滚变得更快、更简便；2、每个服务都可以单独扩容。在需要发布新功能时，可以用插件的形式添加到系统中而不需要重新部署整个系统。3、提供据接口集成，而不是以数据库的方式同其他服务集成。

缺点是：1、增加了不同团队之间交流成本的提高；2、基于微服务架构的分布式系统的测试和管理复杂度大幅度提高；3、分布式部署会给团队的DevOps 能力提出更高的要求。

由此我们可以想见，微服务是个很好的架构，加速了持续集成和持续部署的实现方式，前提是你的团队已经具备很想的DevOps实践能力和沟通协作要求。我们不能不对微服务产生爱之深，恨之切的想法。

东方瑞通成立于1998年，总部在北京，分别在上海、广州、天津、武汉、济南、深圳、成都、重庆、杭州和西安建立了直营分部，全国拥有超过40间专业培训教室、40多位专职讲师及180多位签约讲师；作为国内企业级IT高级技术&管理培训的领军机构，为数千家企业客户提供员工外派（公开课）和团体定制培训服务，累计培训专业人才数十万名。

残混。

通俗