微服务架构原理开发实战：不看此文你还真不知道微服务是个什么鬼

微服务概述

◎微服务的概念

◎微服务与SOA

◎单体式架构

◎微服务架构概述

◎微服务的挑战

笔者在职业早期曾被教导，做一件事最好能理论先行。虽然现实中理论和实际应用会有很大的差距，但是经验告诉我们，理论不仅可以帮助我们更系统地理解事物的本质，而且能科学地选择事情的发展方向。

微服务并不是一个新的概念，从其提出至今热度一直不减，而且.随着技术的不断创新，不同的技术团队会产生不同的理解，这也导致了大家都在做微服务，也都想做好微服务，但具体的软件设计或架构实践有很多不同。

微服务的概念

关于最早的微服务概念有很多版本，据说50年前就已经开始使用微服务的概念了，如UNIX的管道设计其实就是微服务设计的一种体现，还有后续提出的面向服务架构( Service Oriented Architecture，SOA) 、企业服务总线( Enterprise Serice Bus ，ESB)等概念，都是微服务的一种。

其实，微服务相对比较正式地被提出是在2011年威尼斯举办的一个软件架构师研讨会上，“微服务” 被描述为-一种提供微小服务的软件架构，在不到一年的时间里，各路大咖开始定义自己理解的微服务。后来，关于微服务的讨论和实践迅速扩散至整个行业，各大公司相继研发了自己的微服务技术框架，打造自己的微服务体系和生态。

一个简单的微服务架构示意图如图1.1所示。

介绍到这里，大家对微服务的理解可能还是一知半解，那么不妨来看看微服务不是什么，也许可以帮助我们更好地理解微服务的概念。这里主要给大家比较面向服务架构（SOA）和单体式架构，这两种架构在微服务被提出之前流行了相当长的时间，而且单体式架构在一些中小型项目中仍然占据很重要的地位。

微服务与SOA

关于微服务讨论最多的就是SOA，有人说微服务就是SOA的衍生版，也有人说SOA包括微服务，当然，也有相当数量的人认为微服务和SOA完全不一样。那么，微服务与SOA到底有什么关系呢？

SOA的定义

SOA（Service-Oriented Architecture，面向服务架构）是一种粗粒度的、松耦合的、面向服务的架构，在架构中使用一个标准的通信协议，通过网络提供应用程序的业务功能服务，且服务都是完全独立部署和维护的，并且可以组合使用。一个SOA的服务应该有以下几个特点。

（1）逻辑上代表某项具有指定结果的业务活动。

（2）服务是独立的。

（3）对消费者而言，服务是黑盒的（黑盒是指一个只知道输入输出关系而不知道内部结构的系统或设备）。

（4）一个服务可以包含其他基础服务，一个SOA服务可以组合其他服务使用。例如，某商城的SOA示意图如图1.2所示。

从图1.2中可以看出，SOA的几个特点还是很明显的。首先，每个服务都代表着一个业务活动；其次，每个业务活动都是相对独立的，并且通过一个统一的数据总线进行交互；最后，一个服务可以包含多个基础服务。这样看来，SOA似乎和微服务不太一样，虽然概念看起来很相似，但为什么实际架构会有这么大的差别呢？下面将仔细梳理两者的概念，看看概念上是否真的相似。

微服务与SOA的异同点

无论是从架构图出发，还是从核心概念相比，经过仔细对比后发现，微服务与SOA的概念异同点如下。

1. 相同点

（1）服务都是独立运行和部署的。

（2）对消费者而言，服务都是黑盒的。

（3）服务都是通过网络通信的。

2. 不同点

（1）微服务间的通信是轻量级的，既可以是不统一标准的，也可以是跨语言的。

（2）微服务是围绕业务功能设计的，但往往不能代表一项完整的业务活动，在服务划分上比SOA的粒度更细、更微小。

（3）SOA可以包含其他基础服务，而微服务本身可以调用其他服务，但不会包含或组合其他服务。两者相比较，微服务更像是基础服务。

概念上的不同导致了两者的发展方向完全不同。SOA更强调两点：一是业务封装；二是统一标准。一个SOA的服务往往包容一套完整的基础业务服务，提供统一对外接口，关于该业务所有的功能都可以通过这个服务来提供。而微服务可能更强调拆分，每个服务都是细粒度的、独立的存储方式，可以轻量级的进行通信，也可以跨语言。战略设计的不同导致了微服务和SOA在实际运用中的架构方式渐行渐远。在一套SOA下的所有服务会定义一个统一的服务标准，消费者也需要遵守相应的标准才能调用相应的服务，这也导致SOA的整体架构显得有些笨重，无论是在原有SOA的体系下开发一个新的服务，还是集成已有的SOA服务，都需要做很多额外的工作。例如，无论是服务提供方还是调用者，都要遵循这个标准去开发统一的接口和客户端，而这样做往往会限制服务双方的技术选型。

那么，这个标准到底是怎样的呢？这里就不介绍具体的SOA接口标准的某个技术实现了，毕竟本书的重点是微服务，感兴趣的读者可以自行学习SOA具体实践。

服务调用设计

SOA的服务调用标准提出了3个核心概念，即服务提供者、服务消费者和服务注册，应用程序可以通过服务注册中心来管理服务提供者的服务信息，服务提供者可以主动向服务注册中心注册自己的服务信息，而服务消费者可以从服务注册中心订阅服务信息，服务注册中心通过消息等方式通知与服务消费者相关的服务提供者的注册信息，SOA服务调用设计图如图1.3所示。

笔者认为SOA的设计精华就在图1.3中，不管微服务是否属于SOA，它也采用了这一设计，可以说微服务和SOA在战术设计上是类似的，但由于战略设计的不同，微服务后来选择了更轻量级的技术实现。或许大家不是很明白，下面举例说明，服务注册与发现实例图如图1.4所示。

一个公司往往有自己的OA系统，而OA系统中有一个最常用的功能——通讯录，通讯录里存储着公司员工的通信方式，如邮件、电话、地址等。当员工的通信信息有变动时，员工会主动在通讯录中更新自己的信息；当新员工入职或老员工离职时，也会有专人新增和删除通讯录中的员工信息。

这时，如果部门秘书给部分人发送邮件，传达部门经理的一些工作任务安排，他（她）可以通过通讯录来查询这些人的邮箱信息，得到邮箱地址信息后，就可以发送邮件了。此时，这个部门秘书就相当于服务消费者，通讯录就好比服务注册中心，而每个员工就是各个服务的提供者。

当然，关于服务注册与发现在实际应用中的场景可能远比这个复杂，功能也更多，这里的例子可能不太恰当，但也能反映最基础的服务处理过程，希望能够帮助大家更快地理解这些概念。

了解了SOA的设计理念后，回到最初的问题，微服务与SOA到底是什么关系呢？微服务是SOA的衍生吗？可能是因为SOA的提出早于微服务近10年，并且运用了很多年，而且微服务的设计方式确实与SOA的一些设计相似，所以很多人都认为SOA的概念应该包含微服务，或者微服务本身就是一种SOA的变体。

但事实上大多数的时候被称为“SOA”的东西与本书中所描述的微服务有很大不同，最常见的例子就是ESB（Enterprise Service Bus，企业服务总线），这里对ESB不做介绍。总之，ESB是一个不太好的实现，完全的服务导向和过度的追求标准化带来了更多的复杂性和技术瓶颈，也许SOA设计之初和现在的微服务目标或倡导的概念类似，但其后来在战略上的偏执，导致了实施者过度关注于技术和标准，忽略了真正的业务价值，最终导致SOA慢慢被微服务所取代。战略思想上的不一致也导致那些致力于敏捷的微服务拥护者完全拒绝给微服务加上SOA的标签。

所以，笔者更倾向于把微服务当作一个独立的新概念，用微服务来定义这种新的架构风格，以区别于SOA的设计体系。

上面介绍的是与SOA相似的架构模式，下面介绍一个完全相反的架构模式，即单体式架构。该架构模式至今仍在软件架构的舞台上占据着相当大的位置。下面通过分析传统的单应用架构模式，帮助我们更清楚地了解微服务的设计意图。

单体式架构

一个新事物的提出，往往伴随着一个旧问题被解决。当我们无法忍受这些问题的时候，就会开始思考，有没有新的方法能够帮助我们摆脱这些问题的困扰，用微服务替代单体式架构就是这样一个过程。那么，与微服务相比，什么是单体式架构呢？单体式架构又有哪些痛点呢？

单体式架构概述

单体式架构又称为单应用架构或单体架构，也就是系统所有的功能，前端页面也好，后端服务也好，所有的功能模块都在同一个工程上开发，最终将所有模块、所有功能都打包在一起，放在一个进程上运行。例如，很多企业的Java Web项目就是将应用程序打成WAR包，然后部署在一个Web容器中运行。总结起来就是8个字：一包在手，天下我有。现在回想一下在

SOA的例子，如果换单体式架构又会是什么样的呢？在单应用模式下，它的架构如图1.5所示。

由图1.5可见，所有的功能都在一个WAR包内，部署在Web容器（通常是TOMCAT）中运行，在资源允许的情况下，可以任意地水平扩展多个Web容器，客户端（通常是浏览器）通过代理服务器（通常是Nginx）定义一些负载策略，反向代理集群的节点，达到负载均衡的目的。

这样的模式问题是显而易见的，系统中没有明确的边界和职责划分，所有代码都杂糅在一起，随着系统越做越大，代码量越来越多，重复的代码随处可见，模块之间调用逻辑杂乱无章，代码质量越来越难以管理，最终导致无论任何人也无法在这套系统上添加任何功能，这套系统让人闻风色变，都不愿意在其中修改任何逻辑。单体式架构模式是笔者接触最早的模式，虽然现在看来，其设计有些不可思议，但不得不承认，单体式架构是在微服务之前最流行、运用最广泛的模式。直到今天，仍然有很多公司和项目在采用这种模式。

然而，任何软件系统都没有经久不衰的解决方案，也没有一开始就很完美的设计，就像人们打游戏，没有万能的装备组合，也没有一开始就很完美的打法，都是随着经验的不断积累，随着对游戏理解的不断加深，才发明了各种装备组合，各种团战战术。软件设计的发展和创造往往也是同样的思路。

单体式架构的痛点

之前提到了单体式架构的特点，就是所有的东西都在一起开发、维护和部署，这套系统就像一个大杂烩，什么都有。这样的系统很明显是难以维护的，举个最常见的例子，没有明确的边界和职责，重复的代码到处都是，改动一个逻辑，就要改动多处，如果单元测试做得不好，就可能或很容易遗漏而产生BUG。

当然，不能否认单体式架构的优点，而且在中小型项目中，它的开发效率和运维的简便性等好处，要远超微服务架构。但是，随着时间的推移，项目越做越大，代码越来越复杂，单体式架构的缺点逐渐暴露出来，有些问题会让团队越来越无法忍受，甚至导致项目的失败。

1. 单体式架构的优点

（1）前期开发效率高。在项目早期，单体式架构有着明显的优势，开发者只需维护一个工程，应用的测试和调试也非常简单。

（2）易于上手。单体式架构的学习成本相对较低，服务之间都是本地调用，不存在分布式事务、会话同步等复杂问题。

（3）易于部署。这个优势很明显，相比微服务或SOA，单体式架构无论是新部署还是升级部署，只要打好一个包在服务器上运行即可。

（4）易于水平扩展。这也是易于部署的一点，由于单体式架构所有的代码都在一个包中，只需完整地复制这个节点，前置一台代理服务器，很容易就能做到水平扩展、集群部署。

2. 单体式架构的缺点

（1）难以维护。代码大量冗余且耦合度高、逻辑松散，导致代码新增或修改困难。

（2）过载的IDE。几乎每个单体式架构到了后期，都没有一款IDE能够保证这样巨大的代码量可以流畅地进行开发和调试，甚至笔者见过一个开发了10年的产品代码，仅是IDE上运行起来就需要半个小时，严重影响开发和测试效率。

（3）过载的Web容器。这与IDE的情况相同，随着包的体积越来越大，Web容器的运行效率也将越来越差。

（4）资源浪费。前面提到过单体式架构易于水平扩展的优点，这也正是单体式架构在水平扩展时的缺点。大家知道，集群部署一般是解决用户并发量大的负载问题。可能只是想扩展应用的存储能力，需要一台I/O读写效率高的机器，但是单体式架构所有的代码都是一体的，且集群的各个节点都完全相等，因此需要提供能够支撑其他模块数据处理能力的CPU或者带宽等相同配置的机器。

（5）部署风险大。这是单体式架构相对比较大的痛点，每当有新功能上线，哪怕是很小的功能，都需要进行整包部署。如果是集群，那么工作量就更大了，而且重新部署了所有功能，可能导致本身没有打算更新的功能出现问题。

（6）很难追求技术创新。如果一个单体式架构经历了比较长的时间，那么它的技术一定是陈旧的，由于都在同一个工程下开发，技术选型会有很多的限制，而且更改之前的技术框架是很难的，除非团队有毅力和很多时间，还要加上领导和资金上的支持，而这对大部分项目而言几乎是不可能的。大家很快认识到这些问题，所有人都觉得这样不行，然后开始想办法，紧接着MVC（Model–View–Controller，模型—视图—控制器）的概念——一种软件的架构模式被提出来。一时间，MVC似乎成了软件架构新的希望，并且迅速在整个软件业流行起来，而且持续了很长时间，包括现在仍有很多微服务的内部结构在采用MVC的模式进行开发。

经典的MVC架构模式

本书中MVC并不是重点，但谈到单体式架构，就不得不介绍MVC，早在1978年MVC的概念就被提出，可以说MVC的出现极大地延缓了单体式架构的衰败时间，它虽然不能从本质上改变单体式架构本身的缺陷，但在很大程度上确实改善了单体式架构代码混乱、难以维护的问题。

MVC将程序简单地划分为3层。

（1）模型层：用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。模型有对数据直接访问的权力，如对数据库的访问。模型不依赖视图和控制器，即模型不关心它会被如何显示或如何被操作。除此之外，模型还负责具体的业务逻辑和算法的编写。

（2）视图层：能够实现数据有目的的显示，即将模型处理的数据通过图形界面的形式进行展示，在视图中一般没有程序上的逻辑。

（3）控制层：负责转发请求或对请求的处理，起到不同层面之间的组织作用，用于控制应用程序的流程、页面的跳转等。

MVC的各层之间保持相对的独立，视图不用关心用户的请求和数据的存储，通过不同的控制器可以连接不同的模型和视图来完成用户的需求。多个视图可以共用一个模型，它实现了一种动态的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。

MVC各组件之间的具体协作如图1.6所示。

由图1.6可以看出，MVC可以让单体式架构的层次更加简单、清晰，代码职责更加独立，虽然不能改变单体式架构本身的结构，但也大大提升了项目代码的可维护性和可复用性。那么，为什么说MVC并不能改变单体式架构本身的结构呢？继续回到图1.5的例子来分析，如果采用MVC的模式，它又将变成什么样子呢？单体式架构MVC结构如图1.7所示。

由图1.7可以看出，与图1.5相比，其架构进行了很大的优化，先是根据业务的领域或一些边界规则将代码横向拆分成各个模块，然后每个模块内部通过MVC的方式进行了纵向分层。但是，外部单体式的结构并没有改变，所有的代码还在一个容器中运行，所以在1.3.2节中所提到的单体式架构的缺点还是存在的。MVC就像止疼药，只能缓解这些问题，但随着项目的逐渐发展，系统的不断扩大，这些问题还是会暴露出来。这时，急需一种新的模式来从根本上解决这些问题，微服务架构就是这种新的模式。

本文给大家讲解的内容是微服务概述

1. 下篇文章给大家讲解的是微服务架构概述；
2. 觉得文章不错的朋友可以转发此文关注小编，有需要的可以扫下方二维码获取；

   

感谢大家的支持！