1. 什么是微服务

在业界中，有两个人对微服务架构的定义是产生了非常深远的影响，一个是 Martin Fowler，一个是 Netflix 架构总监 Adrian Cockcroft，Netflix 公司对整个微服务架构的推进起到决定性的作用，相信已经对微服务有过一定接触的同学对 netflix 不会很陌生，前期的 Zuul，Hystrix，Eureka，Ribbon 等著名开源组件就是由 Netflix 所进行开源。

Martin Fowler 在《Microservices》
https://static1.haohuo.net/uploads/files/2024/0616/2668660/2668660_microservices.html 中有一段对微服务进行了一个核心点的定义

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

这一小段是《Microservices》最重要的定义片段，微服务是一种架构的风格，在这个风格下勾勒出几个核心点：

1. a suite of small services：一组小的服务；
2. running in its own process：独立的进程；
3. communicating with lightweight：轻量级的通讯；
4. built around business capabilities：基于业务能力构建；
5. independently deployable：独立部署；
6. a bare minimum of centralized management：最小的中心化管理。

1.1 一组小的服务

一组 “小” 的服务，这个小其实是相对而言的，原来的单体服务都是把所有的业务大而全的打包在一个单体结构中，而微服务将这些单体结构进行拆分，形成一个一个独立的服务，这个小是相对原来大而全的结构而言。

很多同学会纠结 “小” 这个点，那么要多小的程度才为之 “小”，因为这个小并没有特别和明确的规定，所有这也引申出来现在很多 DDD 领域驱动设计来指引微服务的拆分，基本上一个微服务能让一个开发人员能独立的理解，就可以称为一个微服务，具体有多少行代码不是关键。

1.2 独立的进程

微服务是运行在独立的进程当中，例如 Java 程序部署在 Tomcat 的容器中，也可以将 Tomcat 部署在 Docker 容器中，因为容器本身也是一种进程，所以微服务可以以进程的方式去扩展。

使用容器进行部署，使得定义，部署与运行一个微服务变的更加简单，由于微服务粒度比传统的 SOA 服务更小，它对 Web 应用服务器的要求也变成更加的轻量级。

1.3 轻量级的通讯

微服务主张使用轻量级去构建通讯机制，我认为是使用基于 HTTP 协议的 API 资源，一般是 RESTful API。不过现在正式投入生产的应用中，微服务之间的通讯绝不止于 RESTful，虽然 HTTP 协议相对来说较为简单，但它在传输的性能和可靠性也存在比较大的局限，特别是 JSON 在序列化也较弱。

所以在微服务内部通讯会使用更多的 RPC 框架，例如 Netty，gRPC，阿里的 dubbo 协议等等，甚至还可以使用消息中间件来完成通讯传输。

究竟我们的服务应该选择 RPC 还是 RESTful，在后面的章节会进行讨论。

1.4 基于业务能力构建

文中强调了服务的规划和划分，是基于业务进行构建，这一点非常的重要，是业务而非技术驱动微服务的设计，这一个观点从而也推动了领域驱动设计（DDD）的发展，越来越多的人尝试将领域驱动设计引入微服务架构的设计中。

例如：在电商的系统中，我们划分服务更多考虑的是业务，例如：用户服务，商品服务，订单服务等等，这个在后面划分服务的章节将会再进行讨论。

1.5 独立部署

在以往的大型独体项目中，部署和发布永远是高悬头顶的达摩克利斯之剑，某一个模块的错误都可能让整个系统崩塌。

但是微服务的一个关键原则是：每一个服务都是系统的组件，均可以独立的进行部署，团队之间是不需要特别的进行协调，当我们开发和部署一个服务时，我们只需要确保测试和部署好一个服务，如果真的把它搞砸了，也不会把整个系统都搞砸。

当然，一个服务挂掉了不会把整个系统都搞砸，还需要建立在一个好的微服务治理上，这个问题我们在后面的章节中也会讨论。

1.6 最小的中心化管理

最小的中心化管理，其实也可以称为 “无集中式管理”， 原来的单体服务需要整个技术团队都是独立的架构团队去进行管理，统一的架构，统一的技术栈，统计的存储。

而在微服务中得益于服务的拆分，人员的拆分，所以在实施微服务将不再受限于系统的技术栈，无论是开发的语言，数据库，缓存都是可以进行自由的选择。从理论上来说，微服务是一种通过网络协议的跨平台调用，只要规定好服务的接口和服务的网络协议，服务本身的技术都是可以自由选择的。

对每个系统本身来说，是最小的中心化管理，但是，如果从整个微服务的系统架构来说，我们需要考虑到整个微服务的注册，发现，降级，监控，编排等等，这也衍生了我们对微服务更多的 “管理中心”，例如我们会使用 SpringCloud 或 Dubbo 框架进行管理。

1.7 究竟什么是微服务

是否我们达到了 Martin Fowler 讲的以上 6 点就是 “微服务”，或者说是否一定要达到以上的 6 点才能称之为 “微服务”。其实也不一定 Adrian Cockcroft 之前也给过微服务一个定义

Loosely coupled service oriented architecture with bounded contexts.

只要是 “松散耦合的、面向服务的、基于有界上下文的” 也可以成为微服务。可见微服务并没有一个并没有百分百的定义，更多是一种风格，我们需要的是理解这种风格对我们技术业务的推动。

2. 是否要实施微服务

上面我们整体的认识了什么是微服务，那么问题就来了，既然微服务已经这么火爆了，那于鏊不要在我们的业务中也实施微服务呢？

是否需要微服务这个问题的答案，要从实际业务中去得到：

2.1 单体应用的瓶颈

在以往传统的系统架构中，我们在构建一个单体结构一般都是由：前端展示层，服务业务层，存储数据层来组成。

业务发展初期，由于所有的业务逻辑都在一个应用中。开发，测试，部署来说都比较的轻量和方便。但随着业务的发展，系统为了对应不同的业务就得往单体项目增加不同的业务模块，慢慢的不断追加的业务模块会使得单体应用变得越来越臃肿。

随着时间的增长，所有的业务都在一个应用里面，往往一个很小的功能修改都可能影响到其他的功能运行。

并且，在单体应用中，各个模块的使用场景，并发量和系统所需要消耗的资源各不相同，资源处在于相互影响和相互竞争，这个就导致了我们很难去评估和预估所需要提供的资源。

上述说的问题，微服务的诞生就是为了解决单体系统变得臃肿难以维系的问题，将不同的功能点拆分不同服务，让服务各自独立运行，同时，由于是独立运行，我们也可以更好的评估每个服务所需要的资源。

2.2 应用微服务的时机

刚刚上述说了微服务可以解决单体应用在臃肿的业务，部署难度大，资源和扩展难以评估，阻碍团队的技术革新等问题，那是否我们就可以直接从单体应用转化为微服务？

答案明显并不是这样，下面是 Martin Fowler 给的 微服务 / 单体 在随着业务和时间进度推移反映到生产力的关系图：

根据上图，我们知道生产力和业务的复杂度是有关系的，在复杂度小的时候采用单体应用生产力会更高，但到了一定得规模，中间有一个临界点，只有过了这个临界点，单体服务的生产力直线下降，这个时候采用微服务才能正在的提升效率。

所以，要不要采用微服务架构，何时采用微服务必须根据业务场景去做评估，实施微服务对架构也提出来很多的挑战，拆分服务也带来了在单体应用中所没有的问题：

例如服务治理的问题，虽然说微服务实现了最小化集中管理，但那是建立在有一个统一良好的治理体系里面，如果忽略治理也可能因为某个局部服务造成整体服务的崩塌。还有分布式所带来一系列复杂性的问题，运维会迎来新的挑战，需要运维的进程数量会大大的增加，还有如何将这些服务进行编排也是一个比较重要的问题。