什么是微服务架构,该从哪些方面深入理解?到底能解决哪些问题呢？

微服务架构概述

微服务在设计之初就是致力于解决单体式架构的问题而出发的，所以它几乎可以解决单体式架构面临的所有问题。虽然微服务本身也有一些缺陷，但丝毫不影响它替代单体式架构成为主流架构的步伐。那么，微服务架构到底能解决哪些问题呢？

微服务能解决的问题

下面从之前总结的单体式架构的缺点来分析。首先，微服务解决了难以维护的问题。微服务本身微小的设计，导致一个服务的职责不会过大，从而轻松地解决了难以维护的问题，单对一个服务来讲，它的代码量不会特别多，量少的东西不一定简单，但一定是好管理的，而且后续介绍的有关微服务更科学的程序设计方法，也会大大增加代码的可维护性。

其次，过载的IDE和过载的Web容器，似乎也随着服务的微小化而轻松解决了，微服务架构中的每个服务都是独立部署的，拥有自己独立的进程，无论是IDE还是Web容器，都可以轻松地承载，而且应用程序的启动和调试效率也要高得多。

然后，对于部署，微服务架构中，服务都是自动部署的（具体的方式后续章节会有介绍），而且每个服务负责的职责都很小，只会部署有变化的服务，所以单体式架构中需要部署全部功能的风险也就没有了。

这样的方式，在应用需要做水平扩展的时候，只需增加需要的服务节点即可，再根据具体增加节点的特性，如存储、CPU、内存等增加具体的符合需求的资源，也就不会出现资源的浪费了。

最后，关于技术创新，微服务本身是独立的，而且每个微服务之间的通信是轻量级的，这就导致微服务之前几乎是没有技术依赖和限制的，服务既可以有自己独立的存储方式，也可以有不同的语言，服务所采用的技术栈也可以是完全不一样的。所以，你几乎可以使用任何你认为合适的技术，当然，做技术选型往往可能需要考虑更多的问题，但至少在项目的服务架构层面，微服务并不会对一个项目的技术选择造成什么困扰。

看上去微服务似乎真的解决了单体式架构的所有问题，那除了能解决这些问题，微服务本身又有哪些新的特点呢？

微服务架构的特点

微服务定义大致反映出微服务架构的一些特点：微服务是小的服务；微服务是独立运行的；微服务的交互是轻量级的，是可以跨语言的；服务的设计是围绕业务的；微服务是可以自动部署的，有集中式的服务管理等。

但随着微服务的发展，它的定义是多变的，每个人在使用微服务架构时的做法都不完全一样，其中有很多很好的实践，有复杂的，也有简单的，似乎很难去界定谁对谁错，毕竟由于软件项目的独特性，每种实践都是在特定的需求和场景下产生的，因此不妨把目光放在它们的共同点上。此前有过无数人的大胆尝试和实践，我们可以通过分析来看看大多数人都在怎样做着微服务。

ThoughtWorks的Martin Fowler是业界的权威专家，他认为虽然很难给微服务的架构一个正确的定义，但可以尝试描述我们认为有合适标签的架构的共同特征。并非所有的微服务架构都具有所有的特征，但是Martin Fowler希望大多数微服务能具有大部分特征。最后，他总结了微服务的九大特征，成为当下这个松散的社区关于微服务的一个宽松的标准。

下面就来看看微服务的九大特征，如图1.8所示。

1. 服务组件化

组件简单来说就是一个可以独立更换和升级的软件单元，就像计算机的内存、显卡、硬盘一样，是可插拔的，而且更换和设计不会影响其他单元。在微服务架构设计中，我们将应用拆分为一个个独立的服务，这些服务像组件一样可以独立更换和升级。每个服务拥有独立的进程，可以独立开发和部署；每个服务可以拥有独立的存储，服务之间通过HTTP等轻量级的通信协议进行交互，而不是传统的嵌入式的方式。

2. 围绕业务组织团队

通常，传统的公司可能会按照技术去组建团队，如测试团队、前端开发团队、后端开发团队、数据库团队、运维团队等，但微服务本身的设计是围绕业务展开的，各个服务按照业务价值来划分边界，这样就导致了微服务的团队组织结构上是必须跨技术能力的，一个团队中可能需要包括各种能力的人，如前业务分析师、测试工程师、前端开发工程师、后端开发工程师、数据库工程师、UI设计师、运维工程师等。

当然，由于微服务小的设计理念，团队的规模不会很大，如亚马逊的“Two Pizza Team”原则，一个团队吃一餐饭只需两个披萨就够了。这样一个团队，工作中的内耗是很低的，因为团队的职责边界更加清晰，团队间沟通不畅或者推卸责任等现象将会得到改善。

3. 做产品而非项目

微服务架构中流行着一句话：“You build，you run it！”意思是你构建的应用，那么由你来负责运行它。

人们在传统的软件项目中，往往以一个做交付的方式来做项目，而不会考虑整个产品的运作方式或生命周期。例如，产品将需求交付给开发，开发将应用交付给测试，测试将构建好的版本交付给运维，运维负责将应用运行起来。

微服务架构的团队组织可以说是麻雀虽小五脏俱全，一个团队往往需要负责项目的全部阶段的工作，微服务团队更像是在做产品而非项目，大家需要关注整个产品的生命周期，负责各个阶段的各种工作，并且持续关注服务的运作情况，从而不断分析，来帮助客户提升业务价值，倡导开发运维一体化，现在很流行的DevOps等角色，也是在微服务流行趋势下所产生的。

4. 智能端点和哑管道

由于微服务本身分离的特点，它并不能像单体式架构那样通过本地的函数调用即可进行服务间的交互，那么选择一个好的远程调用的通信方式是关键。

在SOA中，有一些较好的实践，如在之前提到的ESB就强调需要将调用逻辑放入沟通机制本身，各个端点遵循统一的标准，由企业服务总线来完成消息路由、编排和转换等功能。这会导致服务间的通信更加繁琐，笨重的调用方式在服务升级或更换时显得尤为吃力。所以，我们需要更加粗粒度、更加轻量的通信机制。微服务社区更倾向于采用另一种方法：智能端点和哑管道。微服务在设计上不只是在意分离，还强调内聚，每个服务拥有自己的领域逻辑，就像是UNIX的管道设计一样。目前最常用的有两种协议：一种是带有资源API的HTTP请求，即人们常说的RESTful API请求；另一种是通过轻量级的消息总线，如使用RabbitMQ或ZeroMQ等来进行消息传递。

5. 去中心化治理

无论是单体式架构，还是SOA，似乎都需要定义一个统一的技术平台标准，但经验表明，这种做法并不好，不是每个问题都是钉子，不是每个解决方案都是锤子，每种技术平台都会有它的短板，一旦规定了统一的技术平台标准，在遇到它的短板时，开发者将感到十分痛苦。

微服务团队更提倡采用不同的方法或标准，使用正确的工具和技术来完成工作。通过轻量级的、粗粒度的通信机制，不同的服务不再需要中心化的技术平台标准，服务可以是不同语言、不同框架的，可以根据不同的业务场景需要来选择合适的技术。

6. 分散的数据管理

分散的数据管理十分符合微服务最初的定义，服务间是独立运行的，每个服务都可以拥有自己独立的存储。当然，关于去中心化数据管理，业界也有很多解决方案，如模型概念上的不同，可以抽象出不同的视图，可以使用领域驱动设计的方式（后面章节会介绍）将复杂的领域划分成不同的限界上下文，这有助于澄清业务边界，强化数据模型上的分离。

微服务除在概念模型上的分散策略之外，还分散了数据的存储决策，让每个服务管理自己的数据库，可以是相同的数据库技术的不同实现，也可以是完全不同的数据库系统。人们把这种方式称为“Polyglot Persistence”（多语言持久化）。

当然，这种做法也会带来一些弊端，如分布式事务等问题，往往需要通过额外的工作来保证事务的最终一致性，但是这丝毫不会阻碍其在微服务架构中的应用，微服务团队往往把这个问题的解决寄希望于服务拆分的合理性上。

7. 基础设施自动化

微服务由于小和分离的特点，往往一个大型复杂的项目运作需要部署很多服务，如果都是人工手动来完成这项工作，那么无疑将会耗费巨大的成本，而且人工容易出错，一旦出错，排查会十分费力，好在基础设施自动化技术在过去几年中发生了巨大的变化，特别是云技术、Docker和K8s等技术的发展，大大降低了构建、部署和运行软件的成本。各种持续集成和持久交付的工具层出不穷，而微服务架构中就需要这样的服务或技术工具来保证服务的构建、部署和测试等工作可以做到自动化。

8. 容错设计

使用服务作为组件的结果就是需要设计的应用程序能够容忍服务的失败。由于服务提供者不可用，任务服务消费者调用此服务时都可能失败，因此服务消费者必须尽可能优雅地对此做出响应。

单体式架构在这方面似乎有一定的优势，由于都是本地函数调用，它无须引入额外的复杂代码就可达到优雅响应的目的，但任何事情都有其多面性，单体式架构的优点是系统复杂度降低了，但缺点也是毋庸置疑的。也就是说，如果服务不可用，可能会影响整个应用，致使其他无关的功能都不可用。

所以，微服务架构中一般最基本的做法是针对每个服务都进行弹性的监控和日志记录，这样能够保证在服务出现故障时快速地监控并加以恢复。有关断路器、当前吞吐量和延迟的信息监控等其他方式，在后续的章节中详细介绍。

9. 演进式设计

现在已经知道了很多微服设计的关键因素，不难看出，要设计一个完美的微服务架构，尤其是对于没有足够经验的团队来说，无疑是很难的。但从软件设计的思路来看，没有设计从一开始就是完美的。

所以，很多情况下，微服务从业者都会以演进的方式进行系统的设计，笔者在工作中也常被项目的业务分析师问道：为什么我看你们总在重构，就不能一开始写代码时把结构设计好吗？这时，笔者反而觉得这是软件设计好的表现，然后很耐心地和他解释软件设计的思路就是这样的。人们称其为演进式设计。

当然，重构也是需要条件的，开发人员应该能够控制应用程序的更改，而且不会降低变更速度。变更控制并不一定意味着改变，但可以通过正确的态度和工具，如单元测试、契约测试等，对软件进行频繁、快速和良好控制的更改。

微服务架构的优势

综上所述，微服务不是SOA，它能直击单体式架构的痛点，在比较其他架构之后，了解到了微服务的九大特性，那么，在实际应用过程中，微服务到底能带给人们哪些便利呢？与其他框架比较，它的优势究竟是什么呢？

当然，一个流程的架构模式必然是有很多优势的，要列举全部的微服务架构的优势不太现实，在这里列举微服架构的几个强大优势，强大到各大公司，如亚马逊、Netflix、eBay，包括国内的某些大公司都开始转型。

（1）微服务架构的一个重要优势在于可以做到故障隔离，应用程序可以不受单个模块故障的影响，这是软件工程尤为重要的一点，微服务是松散耦合的，各个部署单元都是独立的，加上服务监控及熔断的机制，可以轻松地保证一个系统的健壮性。无论是运行还是部署，各个服务都可以做到完全独立。

（2）微服务架构消除了项目需要长期保持单个技术栈的状况，微服务的分散式设计本身就鼓励开发者在不同的场景和需求下使用最合适的技术，而且服务本身运行的独立性和通信的轻便性也保证了开发者在做技术选型时不会受到太多的限制。

（3）微服务架构使新开发人员更容易上手，微服务架的复杂性是本地化的，服务前较低的依赖可以让开发人员不用过多地关注服务之外的逻辑，而只关注本地服务的业务，再加上服务本身小巧的特性，单个微服务的业务不会特别复杂，新开发人员很容易就能上手，对项目整体而言，也可以通过对各个服务的熟悉，来逐步了解整个系统的全貌。

（4）微服务架构除了在技术上能带来诸多好处，在企业的组织结构上也能起到优化作用。微服务架构通常是围绕着业务进行设计的，那么它的团队也常常围绕业务的价值和优先级进行配置，从而使团队组建者能够完全专注于所分配服务的特定扩展和可用性要求。因此，团队往往是全能的、高效的，同时也是跨职能的。这样的团队也带来了外包的灵活性，虽然许多企业主希望能够将工作转交给第三方合作伙伴，但他们常常担心自己的知识产权，微服务架构则可以满足企业在不披露其核心服务的情况下，将其与非核心业务功能外包的工作分割开来。

这些令人印象深刻的优势使微服务看起来非常诱人，那么微服务架构就是我们要找的完美架构了？当然不是，与前文所说一样，并不是每个问题都是钉子，不是每个解决方案都是锤子，微服务架构自然也有其缺点，而微服务架构的优势也并不是每个项目都能发挥出来的，可能还取决于具体项目技术和组织等各种内在和外在的因素。

微服务的挑战

仅仅是因为某些事情在整个行业风靡一时，并不意味着它没有任何缺点。相反，站在风口浪尖，微服务所面临的挑战也不会小。微服务就是为了应付那些大而复杂的项目而诞生的，所以往往面对的问题都不会太简单，而且似乎很多团队在做微服务转型时都遇到了不少困难，其中不乏一些很有经验、很成熟的团队。

那么，使用微服务究竟有哪些难点呢？微服务本身又有哪些缺点呢？

使用微服务的难点

要评价一个软件架构或技术框架的缺点，笔者认为最直接的就是看这个架构或技术是否好用，使用过程中的难点就代表着这个架构或技术框架的缺点。微服务也应该如此，微服务在使用过程中的难点如图1.9所示。

1. 分布式系统可能很复杂

微服务的架构设计导致了它一定是分布式的，所以分布式系统的难点，几乎微服务全都有。由于一切都是组件化的，而且各个服务都是独立的，因此必须仔细处理模块之间的请求，为了保证系统的健壮性，需要专门额外的代码去监控服务的健康状态，记录和收集各种日志，否则当远程呼叫中断或延迟时，事情会变得更加复杂。

2. 事务管理可能很痛苦

微服务具有分散的数据管理特性，服务不仅可以拥有独立的数据存储，而且可以使用不同的技术实现。这就导致了如果需要做到事务的一致性将变得非常困难，当然困难还是有办法解决的，如现在比较流行的分布式事务最终一致性的解决方案等，也有不少的开源框架来做这件事。但是这无疑给系统实现增加了相当的复杂度，而且针对这些复杂度而产生的工作可能对用户来讲，并没有直接的业务价值。

3. 微服务的测试可能很麻烦

与单体式架构比较，微服务的测试可能很复杂，单体式架构往往是一些外部组件依赖，如数据库，而一个微服务架构的系统，往往一个完成的业务功能测试需要依赖多个服务组合共同完成，而且服务之前可能会存在调用顺序的依赖，在某一个时间点上，同一个微服务可能具有多个版本，这无疑又增加了测试和调试的成本。

4. 运维部署要求较高

由于系统被拆分为多个服务，部署时需要了解服务整体的关联关系，工程师除需要使用和搭建自动化技术来进行服务部署之外，还需要对整个系统进行有效的监控。因此，DevOps的角色是必需的，而很多企业或项目，一个全职的DevOps无疑是奢侈的。

5. 通信成本较高

微服务都采用远程的方式进行调研，通常会采用轻量级的HTTP协议或消息机制进行通信，所以可能在规模不大时与本地函数调用的区别不会很大，但随着项目时间的推移，系统规模的扩大，服务间的调用越来越频繁，获得单个业务结果的调用链越来越长，这时通信成本的消耗将是可怕的。

微服务不是银弹

综上所述，微服务并不是万能的，它会有各式各样的问题，只不过目前我们尚能接受，或者说它带给我们的好处远大于这些缺点。而且，这些问题并不是没有解决方案，毕竟有些问题可能在其他架构中仍然存在。

例如，部署难度大，我们可以使用一些易用的平台或工具，来帮助快速地搭建自动部署的流水线，如Jenkins、PaaS平台等技术；又如，难以测试多版本的问题，可以通过WireMock等技术消除依赖，把测试做到尽可能的单元，然后建立良好的契约测试规范，保证不同版本的兼容测试；再如，分布式事务，如二段提交、补偿事务、最终一致性等方案也都比较成熟；此外，还有服务监控和容错及日志记录等，Spring Cloud提供了相应全面的框架来实现这些功能，这些方案和技术都会在后续章节中介绍。

当然，即使解决了这些问题，微服务仍然不能作为一个银弹，毕竟软件工程本就没有银弹，甚至有人认为微服务并不能代表软件架构在未来的发展方向。我们也无法评估现在的微服务架构是否成熟，但这丝毫不会阻止勇敢的程序员探索和追求真理的步伐。

我们希望微服务变得越来越成熟，就如同希望自己的系统组件化做得越来越好一样，至少目前看来，微服务是一条值得走的路，虽然我们无法确定这条路最终会走到哪里，但是对事物本质和真理的探索及追求技术卓越的脚步永远不会停下。

觉得文章不错的朋友可以转发此文关注小编，有需要的可以扫下方二维码获取资料~

感谢大家的支持！