# 微服务化架构

## 微服务化架构**(MicroServicesArchitecture)**

服务架构的出现，解决了水平分层架构以及SOA架构拆分不彻底的问题。微服务架构是Martin Fowler 在2014年提出的架构模式（如图5）。

![](/files/-Ltdv8ZlVaDj-xeLe9EU)\
图5微服务定义

微服务首先按照业务领域模型垂直拆分，即根据不同的业务功能单元进行垂直拆分。对垂直拆分后的服务，在水平方向继续进行拆分。

#### 1.   特点

微服务架构有如下特点：按照业务领域拆分服务、一系列小服务构成、服务独立部署、独立运行、服务间去中心化管理（任何一个服务都可以采用任何开发语言 C/PHP/Go/Java等，也可以运行于任何的平台Linux/Windows等）。

#### 2.   例子

二手交易平台转转，包括了用户功能、商品功能、交易功能、搜索功能以及推荐功能。各个业务单元相对独立，首先按照业务垂直拆分成用户、商品、交易、搜索、推荐微服务。对每一个功能单元（商品等），继续进行水平拆分，分为商品网关层、商品业务逻辑层、商品数据访问层、商品DB/Cache，对用户、交易、搜索、推荐等业务同样方式进行水平拆分，最终微服务架构如图6:

![](/files/-Ltdv8ZnK8DP5LfGadtG)

图6微服务架构

#### 3.  微服务架构组成元素

那么典型的微服务架构由哪些元素组成呢？如图6，包括网关、微服务业务逻辑层（聚合层）、数据访问层（原子层）、数据存储、注册中心、配置中心。网关负责请求接入，聚合层用于各种业务逻辑的处理，数据原子层用做数据访问代理，提供ORM、数据Sharding以及屏蔽底层存储的差异性等功能。

因此，从业务角度看，微服务架构本质上是一个业务架构，对业务了解越深刻，微服务拆分越合理；从系统角度看，微服务架构是水平分层架构和SOA架构的结合体。

#### 4.  为服务架构的缺点

采用微服务架构后，一方面请求链条变长，对请求响应要求苛刻的场景不适合微服务架构；另一方面服务变多，实施数据一致性的难度变大，对数据要求强一致性的场合也不适合使用微服务架构。

采用微服务架构后，项目能够做到快速迭代，持续交付。微服务架构也存在明显的弊端：开发人员除了关注业务逻辑的实现外，还需要在微服务模块里处理一系列问题，比如服务注册、服务发现、服务通讯、负载均衡、服务熔断、请求超时重试等，这是非常糟糕的。业务开发团队的强项在于业务理解，而不是技术。

能否让业务开发人员仅关注业务开发，服务间通讯以及请求管理功能不再关心？服务网格架构解决了这个问题，让业务开发人员真正解脱。

### **服务网格架构(ServiceMesh Architecture)**

#### 1.   定义

服务网格由Buoyant公司提出，2017年初Buoyant公司CEO William Morgan给出服务网格的定义如下 （图7）：

![](/files/-Ltdv8Zpl4fgjGKAjTC2)\
图7服务网格定义

如果用一句话来解释什么是服务网格，可以将它比作是应用程序或者说微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用服务网格也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。

服务网格是一个基础设施层，用于处理服务间通信。对于有着复杂拓扑结构的云原生服务，服务网格负责实现这些服务间请求的可靠传递。在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，并对应用程序透明。

#### 2.   特点

Service mesh有如下几个特点

l 应用程序间通讯的中间层

l 轻量级网络代理

l 应用程序无感知

l 解耦应用程序的重试/超时、监控、追踪和服务发现

#### 3.   理解服务网格

我们来看一个例子，如图8:

![](/files/-Ltdv8Zr1jZ1Js2WRPG2)

图8服务网格例子

一个应用请求首先发送给远程的服务网格实例，服务网格完成服务发现、服务通讯、负载均衡等完整调用流程，最后将请求发送给目标服务。

继续来看一下服务网格的架构，如图9:

![](/files/-Ltdv8Ztrw7OuEcFHEC6)

图9服务网格架构

服务网格作为 sidecar运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在服务网格中实现。

因此服务网格是一个基础设施层，独立于服务之外，对服务透明，实现了请求的可靠传递。有了服务网格，业务开发人员再也不用关注服务发现、负载均衡、服务重试、熔断等，可以专注在业务开发上。

#### 4.  未来

开源的服务网格产品陆续发布出来：来自Buoyant公司的Linkerd、来自Lyft公司的Envoy、来自nginx的nginmesh以及来自Google/IBM/Lyft公司的Istio等。最值得关注的当数Isto，出身名门，王者风范，期待Istio像k8s一样成为现象级的重量产品。

无服务器\\(Serverless\\)计算（如Amazon的Lambda）正好需要Service Mesh的命名和链接模型，这让Service Mesh在云原生生态系统中的角色得到了彰显。服务识别和访问策略在云原生环境中仍显初级，而Service Mesh毫无疑问将成为这方面不可或缺的基础。就像TCP/IP一样，Service Mesh将在底层基础设施这条道上更进一步。

服务网格这个词仅出现一年的时间，服务网格产品实施落地还需要一些时间，期待后续继续完善，使业务开发同学能够真正回归业务开发本身。

## 总结

互联网架构的演进，看似简单，但这其中凝聚了无数IT人的努力和智慧。不断增长的业务需求是技术发展的动力，期待将来会有更多更好的互联网架构诞生。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://tuonioooo-notebook.gitbook.io/micro-services-subject/jia-gou-she-ji-pian/hu-lian-wang-jia-gou-yan-jin-fen-xi/wei-fu-wu-hua-jia-gou.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.