3.3.2 微服务架构与其他架构的区别

微服务架构是由多个服务系统相互组合构成的，它不是单一的服务。在开发软件的过程中，微服务异构性的优点，使得设计人员可以使用许多新技术，从而区别于传统系统开发及软件开发方式。在实际的设计工作中，为了使微服务架构更加完善，需要对微服务进行进一步的研究。微服务本身就具有多个功能，在微服务架构方面，各功能之间是相互独立的；在系统方面，功能片段会对系统其他部分产生一定的限制和制约，从而能够及时解决一些故障问题。尤其是当微服务架构发出请求后，处理信息的速度一般很快，效率较高，通过容器能够进一步扩展解耦性，进而在硬件底层就可以将软件分离出来。在软件设计或系统开发的过程中，运用微服务主要是为了对应用进行必要分解，进而有助于工作人员对应用进行合理部署。微服务架构与其他架构的区别如图3-10所示，具体如下。

1. 微服务架构与单体架构

单体架构是最为简单的软件架构，常用于传统的应用软件开发及传统Web应用。一个单体应用具备所有功能，如图3-10（a）所示。这种架构存在很多弊端：整个架构包含了很多模块，模块与模块之间的边界不清晰，存在许多相互依赖的关系，代码质量也很低，很小的代码修改错误就会造成整个项目瘫痪，项目复杂度很高；随着时间的推移，应用程序积累的技术债务越来越多，导致其代码及设计很难修改；随着代码量的逐渐增多，构建与部署的时间也越来越长，每次功能的变更或缺陷的修复都会导致整个应用的重新部署，部署的速度逐渐降低；单体架构的扩展能力极差，只能进行整体扩展，而不能像微服务架构那样结合业务模块的特点进行伸缩；单体架构使用统一的技术平台或方案来解决问题，而不能使用不同的开发语言和架构。而微服务架构则解决了这些问题，它将应用拆分成一个个小但关联的服务，服务可以独立部署且服务之间具有隔离性，相互之间没有依赖关系，同时，微服务的可扩展性极好且具有技术异构性，设计人员可以根据需要采用不同的新技术或编程语言来解决问题。

单体架构实际运行在一个进程中，为了优化其本身，它将代码的实现、业务逻辑的实现进行了区分，其本质是在逻辑上进行划分。在单体架构中，整个架构分为不同的模块，每个模块对应不同的功能，随着时间的推移，单体架构中的功能会逐渐增多，而为了满足增加的需求，设计开发人员就需要不停地进行开发迭代、运营维护，如果将单体架构比作房子，这个房子分为厨房、卧室、卫生间、阳台、客厅等多个空间，不同的空间有不同的用途，客厅供客人娱乐，厨房供主人做饭等。随着时间的推移，房子中的人逐渐增多，需要不停地扩展空间，最后就成为一个庞大的房子了，这使得房子的管理变得困难。

微服务架构则解决了单体架构的问题。微服务架构将应用拆分为小且相互联系的服务，服务之间既可以独立部署、相互隔离，还能共享资源（如数据库）。同时，模块之间用接口相连，进行轻量级通信，并对通信做日志记录，还可以采取安全防护措施。如此一来，一个清晰、通信自由的微服务项目就建立了。如果把微服务架构也比作房子的话，那么其就是对房子做一个区分整理，每一个功能都当作一个房子来建，可以单独建一个卧室，当主人需要休息时就可以直接去卧室休息。如果需求不断增加，就不停地单独建房子，最后组建成为一个“小区”，再在小区内部修路（模块之间用接口相连，进行轻量级通信）、关键位置安装摄像头（对通信做日志记录）、进行保安巡视检查（采取集体安全防护措施）等工作，从而构建了一个和谐安定的良好居住环境。

2. 微服务架构与RPC架构

RPC（Remote Promote Call）既是一种进程间通信方式，也是一种远程调用方式。它允许像调用本地服务一样通过网络通信调用不同的远程服务，例如，有两个部署在不同服务器上的应用，其中一台服务器上的应用想要调用另一台服务器上的应用中的函数，由于不在同一个服务器上，不能直接调用，需要通过网络来进行，其主要目的是让远程服务的调用变得更简单、更透明，RPC架构示意如图3-10（b）所示。

RPC的核心思想是隐藏远程调用的复杂性。但是很多RPC的实现隐藏得有些过头了，进而会造成许多问题。使用本地调用不会引起性能问题，但是RPC会花大量的时间对负荷进行封装和解封装，更不用提网络通信所需要的时间。这就意味着，要使用不同的思路来设计远程和本地的API，而简单地把一个本地的API改造成为跨服务的远程API往往会带来问题。最糟糕的情况是，开发人员可能会在不知道该调用是远程调用的情况下对其进行使用。

对比微服务架构与RPC架构，不难发现，它们有很多不同之处：在通信方面，RPC与微服务的通信方式存在差异，RPC通过RPC方式，而微服务则使用REST API，其提供了一组设计原则和约束条件，主要用于客户端和服务器交互类的软件；在功能方面，RPC只能支持一种编程语言，而无法像微服务那样对于不同的服务可以使用不同的编程语言来实现。

3. 微服务架构与面向服务的架构

SOA（Service Oriented Architecture，面向服务的架构）是一种设计方法，其通过对单体架构的水平拆分及垂直拆分演变而来。SOA强调用统一的协议进行服务间的通信，服务运行在彼此独立的硬件平台上，但是需要通过统一的协议接口相互协作。

通过对比图3-10（c）与图3-10（d）不难发现，微服务架构其实和SOA类似，微服务架构在SOA的基础上进行了改进，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，也就是说，将原有的单个业务系统拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。而二者最大的区别在于是否能去中心化，其相关内容在上节做了详细的说明。在此，通过一个贴近生活的例子，让读者更加清楚二者之间的区别。就像运营一家餐厅一样，SOA采用员工责任制，每个员工有自己要负责或管辖的范围，厨师只负责烹饪美味的菜肴，收银员只负责收款，服务生只负责端盘子，后勤只负责刷盘子，所有的员工使用同一种语言交流，从而方便工作协调。而微服务架构在SOA的基础上进行优化，其让餐厅员工之间的职责分配更加明确，提供并允许更多的方式让员工之间更好地交流，从而使餐厅运营得更加井井有条。