下载掌阅APP，畅读海量书库
立即打开
微服务架构是过去几年架构设计领域的热点，接下来就先讨论一下微服务是什么，以及微服务架构带来的收益。
业务发展初期，业务流量很小，对业务迭代效率的要求很高，使用单体服务开发灵活，部署简单。随着业务的快速发展，业务复杂度越来越高，同时业务开发人员也急剧增加，单体服务逐渐暴露出来一些问题，主要问题如下。
（1）开发效率低
业务逻辑都集中在单个服务中，所有的开发者都在一个项目里面进行修改，代码并入时经常会出现相互等待和代码并入冲突的现象，严重影响开发效率。另外，多人同时操作一份代码，出错的概率也会增加。
上线方面，同一时刻有多个特性需要上线观察，为了保证线上服务的稳定性，一般要求特性上线以灰度的方式进行，不同特性之间串行上线。业务迭代比较快时，多个特性同时需要上线，就需要排队顺序等待，这样就会严重影响业务的迭代效率。
（2）可维护性差
业务逻辑都集中在一个服务里面，单个开发者不太可能完全掌控整个业务，因此业务修改和问题追查定位都非常困难。由于很少有人能够对业务非常熟悉，增加新功能或者修改原有功能时更多像是在打补丁，导致代码质量和可维护性越来越差，各种功能耦合在一起，新人接手的时候都不知道从何下手。
（3）架构扩展性差
不同模块可能有不同的架构要求，单体服务很难照顾到大家的差异化需求，如果想针对某个模块进行新架构和新语言的调整与支持，也比较困难。
（4）部署不灵活
任何一处很小的改动，都需要对整个服务进行编译、部署和上线，这可能会影响整个系统的稳定性，同时很难对某个特定的模块进行单独的容量规划和部署设计。
（5）健壮性差
单体服务的所有模块都在一起，某个模块出现严重问题，会导致整个业务不可用。当业务代码规模很庞大时，系统的故障点会很多，严重影响业务的健壮性和可用性。
微服务就是为了解决单体服务的上述问题而生的，按照微服务权威专家Martin Fowler的定义，微服务架构是将单个服务拆分成一系列小服务，这些小服务都拥有独立的进程，通过HTTP RESTful API之类的轻量级通信方式进行通信，而作为独立的业务服务，则可采用一些自动化部署机制独立部署，每个服务可以使用不同的开发语言和数据存储技术，实现去中心化的服务管理。
微服务架构的核心诉求是支撑业务敏捷开发和部署，因此微服务架构的本质是如何优雅地支持微服务的“拆分”和“组合”，如何进行合理的架构拆分，如何最大限度地减少微服务之间沟通的成本，这是微服务架构的关键所在。
微服务作为一个新技术，虽然在最近几年才受到越来越多的重视和推崇，但很早之前就有充足的理论基础。微服务的很多理念在《康威定律》中被充分阐述过。康威定律指出，设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构，康威定律对系统架构设计有重要的指导价值，核心要点如下。
1）架构设计必须解决沟通问题，好的设计应该降低沟通复杂度。这里蕴含高内聚、低耦合、服务隔离等架构设计的一些思想。
2）一个系统没法一次做完美，迭代升级应该是常态。这里蕴含持续集成、敏捷开发、自动部署、容错设计等思想。
3）人员组织结构一般会与系统设计趋同，你想要什么样的系统就需要什么样的组织结构。
4）大系统终究会拆解成小系统，“合久必分，分而治之”；互联网大多会变成大系统，微服务是架构发展的一个非常自然的演变状态。
康威定律完美诠释了微服务架构的必要性和合理性，人与人沟通复杂，当问题复杂时，需要拆分组织来解决沟通问题；组织结构影响设计，通过组织拆分来改善沟通，从而形成拆分的设计（微服务架构）；被拆分的子系统设计是内聚的，对外边界是简单明确的，如果它能降低沟通成本，设计就是合理的；不要指望一个系统是大而完美的，它一定是迭代出来的。
微服务不只是个技术问题，更多的是关于组织和团队的问题，系统架构和组织之间存在映射关系，如果组织结构不支持，则无法建立高效的系统架构，反之也是这样。
互联网业务的两个显著特点是业务发展快和业务高并发，微服务在这两个方面均有很大的收益，通过有效支撑业务创新和高并发架构，微服务架构成为传统架构演进时的必然选择。
通过将单个服务拆分成多个微服务，多个微服务可以独立开发、独立测试、独立运维，不同团队可以并行开发，互不影响，可以有力地支撑业务的快速迭代，方便业务创新和试错。
互联网业务通过业务模式创新和运营模式创新，用户和流量变化很快，需要从架构层面支撑业务流量的伸缩变化。微服务架构将单个服务拆分为多个子服务，每个微服务均可以独立进行容量评估，非常灵活，可以很好地支撑业务的高并发需求。