系统架构：我理解的微服务

最近在研究微服务，在网上搜索找到和阅读了很多相关的资料，感谢众多IT从业人员的努力付出，本文结合自己的理解做一个总结(本文部分观点和资料均来源于网络)。

一、为什么需要微服务

在阐述什么是微服务之前，先来聊聊单体应用会面临的一些问题。

本质上来说，单体应用的核心是由模块实现的业务逻辑，定义了服务、领域对象和事件。围绕核心的是与外接口对接的适配，包括了数据访问与WEB组件等，暴露了API或者实现了UI。虽然有一个模块化的架构，但应用程序会被作为一个整体进行打包和部署，实际打包和部署方式决于应用程序的语言和框架。例如，Java应用程序被打包成 WAR包部署在Tomcat之类的应用服务器上，或者是打包成可执行的JAR，等等。这种风格的应用很容易开发，也很容易测试，同样易于部署，只需拷贝打包好的应用程序到服务器，当然，还可以通过运行多个副本和结合负载均衡器来扩展应用。这些在项目的早期阶段运作良好。

但是，这种简单的方式有很大的局限性。这样的应用有一个趋势，随着时间推移，不断增加新需求，不断更新和不断修复问题，应用会变得越来越臃肿。一旦应用程序成为了一个庞大、复杂的单体，整个开发团队势必陷入了一个令人痛苦的世界。任何改善性的开发与交付模式的尝试都将原地徘徊，一个主要问题就是应用程序实在是过于复杂，对于任何一个开发人员来说，都实在太大了，这是可以理解的。最终，正确地BUG修复和新功能的实现都将变得举步维艰，而且这个趋势就像是自由落体。基本代码难以理解，那么改变将不会变得正确，最后得到的是一个巨大得不可思议的泥球。

除此之外，应用程序的发展规模也将会受到限制。因为应用程序越大，启动的时间就会越长，性能会受到影响，生产力也会受到制约。另一个大问题就是持续部署，复杂的单体应用本身就是持续部署的障碍。复杂应用变化时所产生的影响通常也很复杂，很可能需要做大量的手工测试，因此，持续部署几乎不可能做到。还有就是，当不同模块存在资源需求冲突时，复杂的单体应用也可能难以扩展，因为这些模块被部署在一起，必须在硬件选择上做出妥协。此外，因为所有模块运行在同一进程，任何模块的一个BUG，比如内存泄漏，就可能会拖垮整个进程，应用可靠性就会成为一个严重问题。同时，由于应用程序的所有的实例都是相同的，该错误将影响到整个应用的可用性。

         如果有这么一个应用程序，它已经发展成为了一个只有少数开发人员（如果有的话）能够理解的巨大单体。它使用了过时、非生产性技术编写的，这时会发现招聘优秀开发人员变得困难，应用程序难以扩展，不可靠。因此敏捷开发和应用交付是不可能的。

那么，面对这些问题，如何避免呢，思路就是将应用程序分解成一个个较小的互连服务，这种小的互联服务就是“微服务”。每一个服务都是一个相对小的应用，有自己独立的架构包括业务逻辑及与外部接口的适配，通常是实现了一组特定的业务功能，可以独立运行。例如订单管理、客户管理等。

事实上，微服务指代的并不是某一个具体的小服务，也不是某一种具体软件架构，而是代表一种新服务治理的思想。其目在于有效的拆分应用，实现敏捷开发和部署。实现在服务与服务之间结构上的“松耦合”和功能上的“统一”。由此可见，微服务本身与具体技术实现无关，所以其扩展性强。每个服务都可以使用各自不同的存储方式将数据存储在不同存储介质上。还可以每个模块都使用不同的开发技术，开发模式更灵活。这样每个模块就是一个单独的项目，对于单独的项目来说，代码量明显减少，遇到问题也相对容易解决。

微服务对于团队建设来说也是有利的，提倡团队工程师能力更高、自我驱动力更强、学习能力理优秀。事先定义好系统的边界和接口，在团队内实行全栈，让团队自治，原因就是按照这样的方式组建团队，其沟通的成本将维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。

*注意：以我个人的理解的来看，微服务更多的是强调服务端的治理，也就是通常所说的后端服务治理，属于应用内部各业务子系统之间的协调处理，对于前端来说（也就是对外接口）原来该怎么就还是怎么样，特别是基于浏览器Web前端页面，原来是用Nginx代理的还是照旧。微服务架构Spring Cloud中对外的Zuul网关也只针对RESTFul接口，而且还是有必要经过Nginx等类似的负载处理。

二、微服务的缺点

         到此为止，微服务可以说是解决了单体应用所带来的发展性问题，然而，根据事物发展的普遍性规则，单体应用拆分后的单个微服务确实是简单了，但是应用总的复杂性并没有因此消除，具体体现在以下几方面：

         第一，拆分服务粒度大小的划分难度很大。设计人员需要对整体也很高强度的掌握，拆分粒度过大或过小都很难达到理想中的效果，甚至有可能陷入新泥潭难以自拔。

         第二，分布式系统本身具有的复杂性。微服务为了应用的扩展而生的，所以必须是分布式的，而分布式本身又是复杂的，主要体现在分布式事务、网络延迟、系统容错等问题的解决难度较大。

         第三，微服务之间的通信成本较高。应用拆分成了子系统，原来没有的系统的间的通讯也就有了，这对服务之间的网络稳定性和通信速度要求比较高，特别是异步通讯和数据一致性的要求，使这一情况变得更为复杂。

         第四，运维成本必然会增加。单体应用可能只需部署一小片应用服务区集群，而微服务架构下这种情况可能就会变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。服务数量的增大，对运维人员的运维、部署工作都会带来较大的挑战。

第五，对于测试也是很大的挑战。在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。

第六，对团队人员的要求明显提高，必须有坚实的DevOps开发运维一体化技能。开发设计人员需要熟知运维与投产环境，运维人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。

三、如何拆分服务

一年之计在于春，一天之计在于晨，一个应用能不能做得好，关键在于设计。在做微服务的路上，拆分服务是一个必须要经历的过程，合理拆分服务是决定应用成败的关键。如何合理地划出拆分边界，个人认为，从以下几个方面考虑：

1、遵从设计基本原则。抛开具体的数据与业务，从软件方法论上规范服务的拆分。

（1）软件架构应该都是稳定的。当前稳定的技术框架组合，简单高效，且无已知漏洞，安全可靠。

（2）遵从共同封闭原则，职责应相对单一。

（3）松耦合，一个服务的变化不影响其它调用它API的客户端

（4）是可以测试的。

（5）团队自主。每个微服务从开发、测试、运维等均相对独立，存储也独立，拥有自己的一套完整的流程。不依赖于其它业务模块。

（6）粒度适中3-5人。粒度过小，一是会造成服务间通信成功过高，二是很难防范由于团队成员变更带来的系统不能持续的风险；粒度过大，难免又回到了单体应用的囧境。

2、基础服务。基础服务本身与具体业务应该是关系不大，可以说是一些相对通用的数据服务，比如用户、订单等。

3、支持服务。可以是一些第三方的内容，如发短信、发邮件、支付网关等，可能与直接业务关系不大，但能起到一定的支持作用。

4、具体业务。属于应用的核心价值，比如流程审批、风控、考勤等。

5、扩展性。拆分的一个重要理由也是最有价值的结果就是提高了系统的扩展性。用户对不同的服务有不同的并发和性能方面的要求，因此服务具有不同的扩展性。把具有不同扩展性要求的服务拆分出来分别进行部署，可以降低成本，提高效率。比如电商平台的搜索服务有很多请求，需要特别好的扩展性，应该把搜索服务分离出来，单独考虑其扩展性的需求。这样可以确保不会因为搜索服务突然繁忙而影响其他的服务。也可以根据搜索服务的特点，设计出适合扩展的部署方案。

6、软件发布。系统中经常变动的部分和基本不变部分一般都符合2/8原则，可以将基本不变的那部分分离出来，单独部署，单独管理。这不仅有利于降低系统的复杂性，精简团队的规模，也有利于在系统发生故障的时候快速定位。如果不做这种拆分，系统在扩展的过程中会浪费很多资源。

7、信息安全。不同的服务可能对信息安全有不同的要求，因此把需要高度安全的服务拆分出来，进行特别的部署，

比如放在防火墙的后面，更有针对性地满足信息安全的要求，也可以降低对防火墙等安全设备吞吐量、并发性等方面的要求，降低成本，提高效率。

四、总结

当然，不是所有系统都适合使用微服务方法。要知道，微服务只是手段，目的是为了敏捷的开发和部署。所以，不要也不需要为了微服务而微服务。

通过以上的分析可以得出，记录和交互型的系统使用微服务方法建设可能获益会比较多，原因是这两类系统在并发性能可能更容易有比较高的要要求，且业务相对独立性也比较高，更容易拆分。但是，在拆分服务的进修要坚持：从基础出发、面向业务、大道至简、分而治之的四个原则，充分考虑已有数据、业务需求、投入产出、组织结构、系统扩展、软件发布和信息安全等方面。不能只从技术角度出发，把服务切成很多细微的小块，这样做很有可能会出现劳民伤财、欲速而不达的结果。