本文共 3855 字，大约阅读时间需要 12 分钟。

一、前言

在开始学习 微服务 之前，我们先来问自己几个问题，个人总结就是：“Who、When、What、How”。

• Who：什么是微服务？
• When：微服务的由来？
• What：它有什么用？能干啥？
• How：我们怎么使用它？（后续文章再详细介绍）

为什么这么说呢？不妨往下看。

随着现今互联网的喷井发展，业务需要、数据量等都变得异常复杂且庞大，而单机系统对于这样的场景变得力不从心，虽然 的提出解决了这一难题，但是 至今以来都没有权威的框架和设计，更多的只是前人的积累和实践，虽然 SOA（面向服务的架构）也是一个不错的选择，但是 SOA 对于企业都是奢侈品，更何况中小企业。所以美国科学家 Eric Brewer 站在巨人的肩上，在其博客上发表了微服务的概念。

2020年，O’Reilly 针对 微服务 进行了一项调查，他们对全球1,502名软件工程师、系统和技术架构师、工程师以及决策者进行了调查，报告指出有77％的组织采用了微服务，其中92％的组织成功使用了微服务。同时有29％的组织说他们正在使用微服务迁移或实现其大多数系统。此外，调查还发现了拥有软件生命周期（构建，测试，部署和维护）的团队使用微服务成功的比例比不拥有微服务的团队高18％。下图给出该调查中，组织何时开始使用微服务的统计，如下图：

因此，这样优异的软件架构风格，怎能错过呢？

二、When

微服务最早由Martin Fowler与James Lewis于2014年共同提出，而微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中（如下图-进程），并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术（如下图-数据库），并保持最低限度的集中式管理。

                                   【单体/微服务—数据库】                                    【单体/微服务—进程】

三、Who

1、概述

在讲解微服务架构之前，我们先来了解一下单体系统。

一个单体应用，一般分为 用户接口（包含移动端和网页端）、服务端应用（Java、PHP等动态网站服务器）和 数据源（数据库和NoSQL等）。如下图：                                    【扩展-康伟定律】 从图中，我们可以看出单体系统就是一个整体，所以如果当其中某个业务模块发生了变化或者出现Bug，就需要整体重新构建和部署。随着时间的累积，各个业务模块很难保持很好的模块化结构，很容易有一个业务模块影响别的业务模块的情况。不管是从扩展的角度，还是部署和维护的角度来说，单体系统在面对业务的复杂化，系统模块之间的耦合也会日趋严重。怎么解决呢？这时就需要上 微服务框架了。架构的演进史图，如下： 那么什么是微服务架构呢？Who 事实上，微服务框架只是将一个单体应用程序拆分为多个相对独立的服务，每一个服务拥有独立的进程和数据，每一个服务都是以轻量级的通信机制进行交互的，一般为HTTP API（REST风格）。每一个服务都是围绕着业务模块来开发、维护和部署，这样开发人员可以独立地进行不同语言的开发，采用不同的数据进行存储，最低限度地进行集中管理。

那么什么是微服务框架呢？Who

其实，微服务是一个模糊的概念，不是一个规定的定理或标准，没有明确的定义。但在前人的积累和实践上总结出了一定的风格，因此，只要系统架构满足一定的风格，就可以称为 微服务架构。

2、微服务风格

根据前人的积累和实践，Eric Brewer提出了微服务架构的九大风格，也就是说只要系统架构满足这九大风格，都可以称为微服务。而这也成为了目前比较公认的微服务风格。

• 组件化和服务：把一个单体系统拆分为一个个可以单独维护和升级的软件单元，每一个单元就称为组件。每一个组件能够运行在自己独立的进程里，可以调用自己内部的函数（或方法）来完成自身独立的业务功能，同时通过服务来完成组件之间的互相协作，以此共同完成业务。而服务则是指进程外的组件，它允许我们调用其他的组件，同时提供明确的通信机制（比如HTTP协议、Web service、RPC等）。

  虽然 组件化和服务 为开发和维护带来了便利，但是也引起了其他的问题。最先便是如何将一个单体系统拆分为各个组件，其边界界定又是如何？其次，使用通信机制进行交互，性能还不如单机系统高。

• 围绕业务功能组织团队：在前文说到的单体系统中，我们将应用分为了用户接口、服务器应用、数据源。如果按此划分团队，便可以划分为我们熟悉的前端、后端、数据库和运维团队。但是如果按照这样来定义微服务的划分，当其中一个团队出现问题，会牵涉到多个团队，往往成本比较高，所以为了节约成本，微服务架构通常被建议按照业务模块来划分团队，这样当其中一个业务不可工作，也不会影响整个系统，系统依然可以正常运作。同时也不会涉及多个团队，减少不必要的沟通和成本。

• 是产品而不是项目：传统的软件开发组织一开始会按业务模块进行划分，然后进行开发。但是当开发完成，将软件交付给维护部门之后，开发团队就解散了。而微服务认为开发团队应该维护整个产品的生命周期，也就是说谁开发谁负责后续的改进，从服务业务来说，微服务能让开发者持续关注软件，并不断改善软件，让软件更好的服务于业务，而且越小粒度也容易促进用户和服务供应商之间的关系。

• 强化终端而弱化通道：微服务的应用致力于松耦合和高内聚，也就是业务模块的划分具有高内聚的特点，而各个业务组件则呈现松耦合的特点。但是组件之间需要通信进行交互，一般的HTTP、Web Service和RPC等，都会造成系统性能低下。微服务框架则建议弱化通信协议的复杂性，推荐使用以下两种：

1. 包含资源API的HTTP的请求-响应和轻量级消息通信协议，比如比较流行的 REST 风格。
2. 用轻量级消息总线来发布消息，如 RabbitMQ 或者 ZeroMQ 等，可以提供可靠消息的中间件。

• 分散治理：微服务框架的每一个组件所面对的业务焦点都是不一样的，因此在选型上有很大的差异，所以微服务架构允许开发者使用各类语言构建组件，各组件之间只需要约定好服务接口即可。不同的业务组件可以根据自己的需要来选择构建平台，而这就是分散治理。

• 分散数据整理：每一个组件都拥有自己的数据源，包括数据库和NoSQL等。并且按照微服务组件划分的规则，划分对应的数据，以此更为精确地管理数据，使数据存储更加合理，同时还可以简化数据模型。

  但是分散数据管理也会带来一些弊端：

1. 因为数据库的拆分会导致原有的ACID特性不复存在，所以需要实现分布式数据库事务的一致性。为了实现其一致性，需要引入其他协议，进而使得开发变得复杂，并且造成性能低下。
2. 拆分数据库会造成关联计算十分复杂。

• 基础设施自动化：由于当前的云计算、测试开发、容器（Docker）等技术已经有了较长的发展，解决了微服务架构造成的多个组件的测试和部署，自动化的部署和测试技术极少了对微服务的测试、构建和发布的复杂性，解放了测试人员和开发人员的工作量。

• 容错性设计：使用服务作为组件的一个结果，在于应用需要有能容忍服务的故障的设计。一般分为两种情况：

1. 任何服务器都可能出现故障、断电和宕机。在此情况下，微服务架构应当可以给出仪表盘，监控每一个节点的状态（上线、下线或不可用）是否正常、吞吐情况、内存等。一旦出现不可用时，微服务系统自动就会切断转发给它的请求，给出故障节点的提示，并且将被切割的请求转发给其他可用节点。
2. 当系统接收大量请求时，可能会出现某个组件响应变得缓慢的情况。此时，如果再有其他组件调用该组件，就需要等待大量的时间，以此其他组件就会因为等待超时而引发自身不可用，继而出现服务器雪崩的场景。当一个组件变得响应缓慢，造成大量超时，如果微服务能够发现它，并且通过一些方法将其隔离出去，这样就不会蔓延到调用者，从而导致服务器发生雪崩。

• 设计改进：微服务的设计是循序渐进的，早期的核心架构在后期不会发生很大的变化，经过时间的推移，核心架构的组件往往就会相对稳定下来，从而成为微服务的核心。而那些需要经常变化的组件，则需要不断地进行维护和改进，来满足业务的发展需要。

三、What

微服务有什么用呢？What ，其实总结下来无非以下几点：

• 通过对巨大的单体式应用进行业务分解，将其分为多个服务，解决了单体系统的复杂性问题，同时每个微服务相对较小，便于开发、维护和部署。
• 每个单体应用不局限于固定的技术栈，开发者可以自由选择熟悉的开发技术，提供API服务即可。
• 每个服务只有比较单一的职责功能，都很简单，只关注于一个业务功能，将业务简单化。
• 易于规模化开发，多个开发团队可以并行开发，每个团队负责一项服务，最后进行最低限度的集中管理。
• 改善故障隔离，当一个服务器宕机也不会影响其他的服务，系统还能继续运作。

四、微服务与分布式系统的关系

其实微服务是分布式系统设计和架构理念之一，它是站在分布式系统开发的积累和实践上提出的，从微服务的风格上看，它并不是为了克服所有的分布式系统的缺陷而设计的，而是为了追求更高的可读性、可用性和简易性，同时也弱化了一致性。

所以说微服务并不是解决了分布式系统的所有问题，只是寻求了一个平衡点，让架构师能够更为简单、容易地构建分布式系统。但微服务框架并不是标准，在某些特特殊的分布式系统中，就需要使用其他的方法来解决，所以正如老话说的：“人不会被尿憋死”，具体问题具体分析，合适才是最好的。

转载地址：https://blog.csdn.net/weixin_43452424/article/details/108974182 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！