什么是微服务架构？Thought公司的首席科学家专家

一、微服务架构简介

微服务架构是一种架构概念，旨在通过将功能分解为离散服务来解耦解决方案。您可以将其视为在架构级别应用了许多 SOLID 原则，而不是获取服务的类。微服务架构是一个非常有趣的概念。它的主要作用是将功能分解成离散的服务，从而减少系统的耦合，提供更灵活的服务支持。

概念：将大型单个应用程序和服务拆分为几个甚至几十个支持性微服务，这些微服务可以扩展单个组件而不是整个应用程序堆栈以满足服务级别协议。

定义：围绕可以独立开发、管理和迭代的业务领域组件创建应用程序。在不同的组件中使用云架构和平台式的部署、管理和服务功能，以简化产品交付。

本质：用一些功能更清晰、业务更精细的服务来解决更大更实际的问题。

二、外观与发展

微服务（Microservice）的概念出现在2012年，作为一种加快Web和移动应用程序开发进程的方法，2014年开始受到各方关注，2015年可以说是微服务元年；

越来越多的论坛、社区、博客和互联网行业巨头开始讨论和实践微服务，可以说进一步推动了微服务的发展和创新。而微服务的流行要归功于 Martin Fowler。

这位老人是个奇怪的人，特别擅长抽象和概念创造。尤其是微服务这个新名词，有一个特点：解释的时候懂，问的时候不知道，讨论的时候打架。

Martin Fowler 是国际知名的 OO 专家，敏捷开发方法的创始人之一，现任 ThoughtWorks 首席科学家。他是面向对象分析与设计、UML、模式、软件开发方法论、XP、重构等领域的世界顶级专家，现任Thought Works首席科学家。 Thought Works 是一家从事企业应用程序开发和集成的公司。早在 1980 年代，Fowler 就提倡使用对象技术来构建多层企业应用程序。他是多本经典书籍的作者：《企业应用架构模式》、《UML Essentials》和《重构》。 ————百度百科三、传统开发模式与微服务的区别

我们先来看看传统的web开发方式，通过对比更容易理解什么是微服务架构。对应Microservice，这种方式一般称为Monolithic（单开发）。

所有功能都打包在一个WAR包中，基本没有外部依赖（容器除外），部署在JEE容器（Tomcat、JBoss、WebLogic）中，包括DO/DAO、Service、UI等逻辑。

图片

优点：

①开发简单，集中管理

②基本没有重复开发

③功能都是本地的，没有分布式管理和调用消费

缺点：

1、效率低：开发者都在同一个项目中修改代码，相互等待，冲突不断

2、维护难：代码函数和函数耦合在一起，新手不知从何下手

3、不灵活：构建时间长，任何小的修改都需要重构整个项目，耗时

4、稳定性差：一个小问题可能会导致整个应用挂掉

5、扩展性不足：无法满足高并发下的业务需求

常见的系统架构遵循三个标准和业务驱动：

1、提高敏捷性：及时响应业务需求以推动增长

2、提升用户体验：提升用户体验，减少用户流失

3、降低成本：降低添加产品、客户或业务计划的成本

基于微服务架构的设计：

目的：有效拆分应用，实现敏捷开发部署

图片

关于微服务的形象表达：

X 轴：运行多个负载均衡器后运行实例

Y轴：将应用进一步分解成微服务（子库）

Z轴：当数据量很大时，服务会被分区（分表）

四、微服务的具体特点

官方定义：

1、一系列独立的服务共同组成一个系统

2、单独部署，运行在自己的进程中

3、每项服务都是为独立业务开发的

4、分布式管理

5、强调隔离

近似标准：

1、由分布式服务组成的系统

2、按业务而非技术组织

3、做一个有生命的产品，而不是一个项目

4、强服务个体和弱通信（智能端点和哑管道）

5、自动化运维（DevOps）

6、高度容错

7、快速进化迭代

五、SOA 和微服务的区别

1、SOA 喜欢重用，微服务喜欢重写

SOA 的主要目的是让企业的各种系统更容易集成。说到SOA，我们不得不说ESB（EnterpriseService Bus）。什么是 ESB？将 ESB 视为连接所有企业级服务的脚手架。通过服务代理，它可以将不同的数据格式或模型转换为规范格式，将 XML 输入转换为 CSV 并发送到遗留服务，将 SOAP 1.1 服务转换为 SOAP 1.2，等等它还可以将一个服务路由到另一个服务，并集中管理业务逻辑、规则和验证等。它还具有消息队列和事件驱动消息传递的重要功能，例如将 JMS 服务转换为 SOAP 协议。服务之间可能存在复杂的依赖关系。

微服务通常从重写模块开始。重写整个单体应用程序是有风险的，而且不一定是必要的。当我们迁移到微服务时，我们通常会从耦合度最小的模块或扩展性要求最高的模块开始，将它们一个一个剥离出来，然后敏捷地重写它们。我们可以尝试最新的技术、语言和框架，然后分别部署。 它通常不依赖于其他服务。微服务中常用的 API Gateway 模式的主要目的不是复用代码，而是减少客户端和服务之间的交流。 API网关模式不等同于Facade模式，我们可以使用future等调用，甚至返回不完整的数据。

2、SOA喜欢横向服务，微服务喜欢纵向服务

SOA 设计喜欢对服务进行分层（例如服务层模式）。我们经常看到实体服务层的设计，美其名曰数据访问层。这种设计要求所有的服务都通过这个Entity服务层来获取数据。这种设计非常不灵活，比如数据层的每一次变化都可能影响到所有业务层的服务。每个微服务通常都有自己独立的数据存储。我们在拆分数据库的时候，可以适当的做一些非规范化，这样就不需要依赖其他服务的数据了。

微服务通常是面向用户的，每个微服务通常直接向用户提供一个功能。类似的功能可能有一种服务用于手机，另一种服务用于机顶盒。在 SOA 设计模式中，这种情况通常使用 Multi-ChannelEndpoint 模式来返回一个考虑所有客户端需求的大而全面的结果。

3、SOA 喜欢自上而下，微服务喜欢自下而上

服务契约是在 SOA 架构设计之初定义的。它喜欢集中管理所有的服务，包括集中管理业务逻辑、数据、流程、模式等。它使用 Enterprise Inventory 和 Service Composition 等方法来集中管理服务。 SOA架构通常预定义各个模块的服务接口。模块系统之间的通信必须遵循这些接口，并且服务被定向到它们的调用者。

SOA 架构适用于 TOGAF 等架构方法。

微服务更加敏捷。只要用户能用，就会先挖出服务。然后，有针对性地快速识别业务需求并进行迭代开发。

六、具体如何实践微服务

要真正应用微服务，需要解决四个问题：

1、客户端如何访问这些服务

2、每个服务如何通信

3、这么多服务，如何实现？

4、服务宕机了，怎么解决？ （后备计划、应急处理机制）

**1、客户端如何访问这些服务

在原来的Monolithic开发中，所有的服务都是本地的，可以直接调用UI。现在按功能划分为独立的服务，运行在独立的Java进程中，这些进程一般在独立的虚拟机上。客户端 UI 如何访问他的？

后台有N个服务，前台需要记住管理N个服务。如果服务离线/更新/升级，需要重新部署前台。这显然不符合我们的拆分概念，尤其是在前台是移动应用程序的情况下。 ，通常业务变化的速度更快。

另外，N个小服务的调用也是很大的网络开销。系统内部还有通用的微服务，通常是无状态的。用户登录信息和权限管理（OAuth）最好有一个统一的地方。

因此，后台的N个服务和UI之间一般都有代理或者API网关。其功能包括：

①提供统一的服务入口，让微服务对前台透明

②聚合后台服务，节省流量，提升性能

③提供安全、过滤、流控等API管理功能

其实这个API Gateway可以有很多广泛的实现方式，可以是一个软硬件一体化的盒子，也可以是一个简单的MVC框架，甚至是一个Node.js服务器。它们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供统一的服务出口，将它们解耦，但API网关也可能成为单点故障或性能瓶颈。

用过淘宝开放平台（Taobao Open Platform）的人很容易理解TAO就是这个API网关。

图片

2、每个服务如何通信

所有的微服务都是运行在独立虚拟机上的独立Java进程，所以服务之间的通信是IPC（进程间通信），有很多成熟的解决方案。基本上有两种最常用的方法：

同步调用：

①REST（JAX-RS、Spring Boot）

②RPC（Thrift、Dubbo）

异步消息调用（Kafka、Notify、MetaQ）

图片

同步和异步的区别：

一般来说，同步调用比较简单，一致性强，但是容易出现调用问题，性能体验差，尤其是调用层级比较多的时候。 RESTful 和 RPC 的比较也是一个有趣的话题。

一般来说，REST 是基于 HTTP 的，更容易实现，也更容易接受。服务器实现技术也更加灵活。可以支持所有语言。同时，它可以是跨客户端的。对客户没有特殊要求。 SDK可以调用，所以使用比较广泛。 RPC也有自己的优势。传输协议更高效，安全性更可控。尤其是在一个公司内部，如果有统一的开发规范和统一的服务框架，其开发效率优势更加明显。这要看自己技术积累的实际情况和自己的选择。

异步消息方法在分布式系统中的应用范围特别广泛。既可以减少调用服务之间的耦合，又可以作为调用之间的缓冲，保证消息积压不会压垮被调用者，同时又可以保证调用者的服务体验，继续做什么他不应该被背景表演拖慢。但要付出的代价是一致性的弱化，需要接受数据最终的一致性；而后台服务一般需要实现幂等性，因为出于性能原因，消息发送一般都是重复的（保证消息被接收且只接收一次是对性能的一大考验）；最后，必须引入独立经纪人。如果没有公司内部的技术积累，对券商的分布式管理也是一个很大的挑战。

3、这么多服务，如何实现？

在微服务架构中，一般每个服务都有多个副本用于负载均衡。一个服务随时可能下线，为了应对临时的访问压力，可能会增加新的服务节点。服务如何相互感知？服务如何管理？

这是一个服务发现问题。通常有两种方法，每种方法都有自己的优点和缺点。基本上，服务注册信息的分布式管理是通过zookeeper等类似技术完成的。当服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），通过心跳维护一个长链接，并实时更新链接信息。服务调用者可以通过 ZK 寻址，根据可定制的算法找到服务，也可以在本地缓存服务信息以提高性能。当服务下线时，ZK 会向服务客户端发送通知。

Client-side：优点是架构简单，扩展灵活，只依赖于服务注册器。缺点是客户端需要维护所有调用服务的地址，技术难度较大。一般大公司都有成熟的内部框架支持，比如 Dubbo。

在服务器端做：优点是简单，所有服务对前端调用者都是透明的。一般来说，小公司会在云服务上部署更多的应用程序。

图片

**4、服务宕机，如何解决

如前所述，Monolithic 开发的一大风险是将所有的鸡蛋放在一个篮子里，一个会繁荣，一个会失败。分布式的最大特点是网络不可靠。这种风险可以通过拆分微服务来降低，但如果没有特别的保证，结局肯定是一场噩梦。因此，当我们的系统由一系列的服务调用链组成时，我们必须保证任何一个环节的问题都不会影响到整个环节。对应的手段有很多：

①重试机制

②电流限制

③熔断机制

④负载均衡

⑤ 降级（本地缓存）

这些方法基本清晰通用，比如Netflix的Hystrix：

img 七、常见的设计模式和应用

有一张图总结了微服务架构需要考虑的问题，包括：

1、API 网关

2、服务调用

3、服务发现

4、服务容错

5、服务部署

6、数据调用

图片

六种常见的微服务架构设计模式：

1、聚合器微服务设计模式

这是最常见和最简单的设计模式之一：

图片

聚合器调用多个服务来实现应用程序所需的功能。它可以是处理和显示检索到的数据的简单网页。也可以是更高层次的复合微服务，在检索到的数据中加入业务逻辑，进一步发布为新的微服务，符合 DRY 原则。此外，每个服务都有自己的缓存和数据库。如果聚合器是一个复合服务，那么它也有自己的缓存和数据库。聚合器可以沿 X 轴和 Z 轴独立缩放。

2、代理微服务设计模式

这是聚合模式的一种变体，如下图：

图片

在这种情况下，客户端不会聚合数据，而是根据业务需求调用不同的微服务。代理可以只委托请求，也可以做数据转换工作。

3、链式微服务设计模式

该模式在收到请求后会生成一个合并响应，如下图：

图片

在这种情况下，服务 A 收到请求后会与服务 B 进行通信，同样，服务 B 也会与服务 C 进行通信。所有服务都使用同步消息传递。客户端将阻塞直到整个调用链完成。

因此，服务调用链不宜过长，以免客户端等待时间过长。

4、分支微服务设计模式

该模式是聚合器模式的扩展，允许同时调用两条微服务链，如下图所示：

图片

5、数据共享微服务设计模式

自治是微服务的设计原则之一，这意味着微服务是全栈服务。但是在重构现有的“单体应用”时，SQL 数据库的非规范化可能会导致数据重复和不一致。

因此，这种设计模式可以用于单体应用向微服务架构的过渡阶段，如下图所示：

图片

在这种情况下，一些微服务可能会共享缓存和数据库存储。但是，这只有在两个服务之间存在强耦合的情况下才有可能。这是新的基于微服务的应用程序的反模式。

6、异步消息传递微服务设计模式

虽然 REST 设计模式非常流行，但它是同步的并且可能导致阻塞。因此，一些基于微服务的架构可能会选择使用消息队列而不是 REST 请求/响应，如下图所示：

img 八、优点和缺点

1、微服务的优势：

重点：可控复杂度、独立按需扩展、灵活技术选择、容错、高可用

①它解决了复杂性的问题。它将一个奇怪的单体应用程序分解为一组服务。虽然功能总量保持不变，但应用程序已分解为可管理的块或服务。每个服务都以 RPC 或消息驱动 API 的形式定义了清晰的边界；微服务架构模式实现了一定程度的模块化。

②这种架构使每个服务都可以由专门负责该服务的团队独立开发。只要服务符合 API 契约文字服务和输入语言检测到不兼容的键盘驱动程序，开发者可以自由选择任何有用的技术。当然，大多数组织都希望避免完全的无政府状态并限制技术选择。然而，这种自由意味着开发人员不再有义务使用在新项目开始时存在的可能过时的技术。在编写新服务时，他们可以选择使用当前技术。此外，由于服务相对较小，使用当前技术重写旧服务变得可行。

③微服务架构模式使每个微服务都可以独立部署。开发人员无需协调更改即可部署本地服务。这些更改可以在测试后尽快部署。例如，UI 团队可以执行 A|B 测试并快速迭代 UI 更改。微服务架构模式支持持续部署。

④微服务架构模式使每个服务都可以独立调整。您只能部署满足其容量和可用性限制的每个服务的实例数量。此外文字服务和输入语言检测到不兼容的键盘驱动程序，您可以使用最符合您的服务资源要求的硬件。

2、微服务的缺点

关键点（挑战）：系统部署依赖、服务间通信成本、数据一致性、系统集成测试、重复工作、性能监控等。

①一个缺点是名称本身。微服务一词过分强调服务规模。但重要的是要记住，这是一种手段，而不是主要目标。微服务的目标是充分分解应用程序以促进敏捷应用程序的开发和部署。

2 微服务器的另一个主要缺点是分布式系统带来的复杂性。开发者需要选择并实现基于消息传递或RPC的进程间通信机制。此外，他们必须编写代码来处理部分故障，因为请求的目的地可能很慢或不可用。

③ 微服务器的另一个挑战是分区数据库架构。更新多个业务实体的业务事务相当普遍。但是，在基于微服务器的应用程序中，您需要更新由不同服务拥有的多个数据库。使用分布式事务通常不是一种选择，不仅仅是因为 CAP 定理。当今许多高度可扩展的 NoSQL 数据库都不支持它们。您最终不得不使用最终一致性方法，这对开发人员来说更具挑战性。

④测试微服务应用也比较复杂。类似服务的测试类需要启动服务和它所依赖的任何服务（或至少为这些服务配置存根）。同样，重要的是不要低估这样做的复杂性。

⑤ 微服务架构模式的另一个主要挑战是实现跨越多个服务的更改。例如，假设您正在实现一个需要更改服务 A、B 和 C 的故事，其中 A 依赖于 B，B 依赖于 C。在单体应用程序中，您可以简单地更改相应的模块，集成更改和一次性部署。相比之下，在微服务架构模式中，您需要仔细规划和协调每个服务的更改。比如你需要先更新服务C，再更新服务B，再修复A。幸运的是，大部分变更通常只影响一个服务，需要协调的多服务变更相对较少。

⑥ 部署基于微服务的应用程序也比较复杂。单个应用程序只需部署在传统负载均衡器后面的一组相同服务器上。每个应用程序实例都配置有基础设施服务的位置（主机和端口），例如数据库和消息代理。相比之下，微服务应用通常由大量的服务组成。例如，每个服务将有多个运行时实例。需要配置、部署、扩展和监控更多活动部件。此外，您需要实现一种服务发现机制，使服务能够发现它需要与之通信的任何其他服务的位置（主机和端口）。传统的基于工单和手动操作的方法无法扩展到这种复杂程度。因此，成功部署微服务应用需要开发者对部署方式有更大的控制力，并实现高度自动化。

九、思考：意识的转变

微服务对我们的看法更多的是思维方式的改变。对于微服务架构：技术不是问题，意识比工具更重要。

微服务的几个设计起点：

1、应用的核心是业务逻辑，根据业务或客户需求组织资源（这个最难）

2、做一个有生命的产品，而不是一个项目

3、阿尔法狼，全栈

4、后台服务实现单一职责原则

5、VM->Docker（到 PE）

6、DevOps（到 PE）

同时对于开发同学来说，有这么多中间件和强大的PE支持也是一件好事。我们还需要深入了解这些中间件背后的原理。通过开源技术实现微服务？

最后，一般会提到微服务离不开 DevOps 和 Docker。理解微服务架构是核心，devops和docker是工具和手段。