微服务架构介绍

朱雀 2022-05-09 07:54 256阅读 0赞

作为现在互联网行业比较火的一个概念，微服务。结合网络的资源自给总结的概念性的东西，后期还会有新的基于技术性的文章总结出来。首先在了解微服务架构之前需要了解的概念有分布式、集群等等，这里是从架构的角度上做为总结。所以先从单体架构讲起。

# 一、单体架构 #

## 1.单体架构 ##

单体架构也被称为单体系统或者是单体应用，就是一种系统中所有的功能、模块耦合在一个应用中的架构方式。用简单的方式理解就是将整个应用包括应用、数据库等都在同一个服务器上。而分布式从简单的角度上理解就是将应用和数据等分开到不同的服务器上，就然后对于应用和数据库进行不同方向上的性能优化等等操作。

## 2.单体架构特点 ##

1.  打包成一个独立的单元（导入称为一个jar包或者是一个war包）部署完成应用之后，应用通过一个进程的方式来运行

![70][]

## 单体架构的优缺点 ##

### 优点 ###

项目易于管理

部署简单

### 缺点 ###

测试成本高

可伸缩性差

可靠性差

迭代困难

跨语言程度差

团队协作难

# 二、微服务架构 #

## 1.什么是微服务 ##

微服务是一种架构风格，一个大型的复杂软件应用，由一个或者多个微服务组成，系统中的各个微服务可以被独立部署，各个微服务之间是松耦合的，每个微服务仅仅关注于完成一件任务并很好的完成该任务。**将一个复杂的软件系统，进行了惨无人道的拆分，但是通过拆分之后，这个复杂的应用系统变的更加的高效。**

## 2.架构风格 ##

所谓的架构风格就是项目的一种设计模式。而我们常见的程序设计模式有以下的四种方式。后面对于每个模式的优缺点进行了详细的比较。

常见的架构风格

客户端与服务器端 ：包括C/S 和B/S两种，而B/S比较特殊。

基于组件模型的架构（EJB）

分层架构（MVC）

面向服务架构（SOA）

## 3.微服务特点 ##

（1）系统是有多个服务构成

（2）每个服务可以单独独立部署

（3）每个服务之间是松耦合的。服务内部是高内聚的，外部是低耦合的，也是比较符合软件设计原则的，高内聚就是每个服务内部的关系是非常密切的，每个服务之间只关注完成一个功能。

## 4.微服务的优点、缺点 ##

###        优点 ###

测试容易

可伸缩性强

可靠性强

跨语言程度会更加灵活

团队协作容易

系统迭代容易

###        缺点 ###

运维成本过高，部署数量较多

接口兼容多版本

分布式系统的复杂性

分布式事务

# 三、MVC、RPC、SOA、微服务架构之间的区别 #

###        1.MVC架构 ###

其实从本质上讲，MVC应该算作是一种设计模式，算作是单体架构的一种。比较有代表性的技术：Struts2,、SpringMVC、Spring、Mybatis、Hibernate等等。

###        2.RPC架构 ###

RPC（Remote Procedure Call），远程过程调用，它是一种通过网络远程计算机请求，而不需要了解底层网络技术的协议。代表技术，Thrift、Hessian等

###       SOA架构 ###

SOA（Service oriented Architecture）面向服务架构

ESB（Enterparise Servce Bus）：企业总线服务，服务中介。主要提供了服务于服务之间的交互。

ESB包含的功能如：负载均衡，流量控制，加密处理，服务监控，异常处理，监控警告等等。

代表性的技术：Mule、WSO2等

微服务架构

微服务就是一个轻量级的服务治理方案，代表技术：SpringCloud，dubbo等等

# 四、如何设计微服务及其设计原则 #

1.AKF分拆原则

2.前端后端分离原则

3.无状态服务

4.RestFul的通行风格

### 1.AKF拆分原则 ###

业界对于可扩展的系统架构设计有一个朴素的概念，通过加机器就可以解决容量和可用性问题。也就是一台机器不够用那就用两台机器。

这个理念在“云计算”概念疯狂流行的当今社会，得到了广泛的认可，对于一个规模迅速增长的系统而言，我们讨论最多问题就是容量和性能的问题。但是随着时间的推进，系统规模的增长，除了面对性能和容量的问题，还需要面对功能与模块数量的增长带来的系统复杂性增长的问题，以及业务变化带来的提供差异化服务的问题。而许多的系统再设计的时候并没有充分的考虑到这个问题，导致系统的重构成为了常态，从而影响到了业务的交付能力，还浪费人力财力！对此《可扩展性艺术》一书中提出了一个更加系统的可扩展模型——AKF可扩展立方。这个立方体沿着三个坐标轴的方向分别是XYZ。

![70 1][]

Y轴（功能）

Y轴扩展会加将庞大的整体应用拆分为多个服务。每个服务实现一组相关功能，例如订单管理、客户管理等。在工程上常见的方案是服务化架构（SOA），比如对一个电子商务平台，我们可以拆分成为不同的服务，组成下面这样一个架构：

![70 2][]

但是通过观察上图，容易发现，当服务数量增多时候，服务调用关系也变得开始复杂。为系统添加一个新功能，要调用的服务数量也变得不可控，由此引发了服务管理上的混乱。所以，一般情况下，需要采用服务注册的机制形成服务网关来进行服务治理，系统的架构设计将变成下图所示：

![70 3][]

X轴（水平扩展）

X轴扩展是面向前面朴素理念是一致的，通过绝对平等的服务复制服务与数据，一解决容量和可用性的问题。其实就是将微服务运用多个实例，做集群加负载均衡的模式。

为了提升单个服务的可用性和容量，对每一个服务进行X轴扩展划分。

![70 4][]

Z轴（数据分区）

Z轴扩展通常是指基于请求者或者用户独特的需求，进行系统划分，并使得划分出来的子系统是相互隔离但又是完整的。以生产汽车的工厂来举例：福特公司为了发展中国的业务，或者利用中国的廉价劳动力，在中国建立一个完整的子工厂，与美国工厂一样，负责完整的汽车生产，这就是Z轴拓展。

工程领域常见的Z轴扩展方案有以下两种：

1.  单元化架构

在分布式服务设计领域，一个单元（Cell）就是满足某个分区所有业务操作的自包含闭环。例如我们上面说到的Y轴扩展SOA架构，客户端对服务端节点的选择一般是随机的，但是，如果在此加上Z轴扩展，那服务节点的选择将不再是随机的了，而是每个单元自成一体，如下图

![70 5][]

数据分区

为了性能数据安全上的考虑，我们将一个完整的数据集按一定的维度划分出不同的子集。一个分区（Shard），就是整体数据集的一个子集。比如用尾号来划分用户，同样的尾号的那部分用户就可以认为是一个分区，数据分区为一般包括以下几种数据划分方式

数据类型 例如业务类型

数据范围 例如时间段，用户ID

数据热度 例如用户活跃度，商品热度

按读写分 例如商品描述，商品库存

### 2.前端后端分离原则 ###

![70 6][]

什么叫做前端后端分离呢！前端和后端在一般的概念上本来就是分离的。这个就要从jsp技术讲起，分工精细才能把一个蛋糕做大，多个领域工程师最好在不需要接触其他领域知识的情况下合作，才可能是效率越来越高。维护也会变的越来越简单。Jsp的模板技术，融合了HTML和Java的代码，使得传统MVC开发中的前端和后端在这个技术中如胶似漆，前端的工作就是做好页面，后端转成模板，发现问题在去找前端解决，前端又看不懂java代码，前后端分离的目的就是将这尴尬的局面打破。

前后端分离的原则，简单的来讲就是前端和后端代码的分离，我们推荐的模式是最好采用物理分离的办法部署，进一步促使更加彻底的分离，如果继续直接使用服务器端模板技术，如jsp把java，js，html，css都堆到一个页面中，稍微有点复杂一点的页面就没有办法维护了。

![70 7][]

这种分离方式有几个好处

1.  前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端用户体验优化效果更好
2.  分离模式下，前后端交互界面更清晰，就剩下接口模型，后端的接口简介明了，更容易维护
3.  前端多渠道集成场景更容易实现，后端服务器无需变更，采用统一的数据和模型，可以支持多个前端，例如微信H5前端，PC前端，Android前端，IOS前端

### 3.无状态服务 ###

![70 8][]

对于无状态服务，首先介绍什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么和这个数据被称为状态。进而依赖这个状态的数据的服务被称为是状态服务，反之称为无状态服务

那么这个无状态服务原则并不是说在微服务里就不允许存在状态，表达的真实意思是要把所有状态的业务服务改变为无状态的计算类服务，那么状态数据也就是相应的迁移到对应的有状态数据服务中。

场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中，就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不需要考虑缓存数据如何同步的问题。

### 4.RestFul的通讯风格 ###

![70 9][]

作为一个原则来讲，本来应该是一个“无状态通信原则”，这里直接推荐一个实践优选的RestFul通信风格，因为他有很多好处：

1.  无状态协议HTTP，具备先天优势，扩展能力很强，例如需要安全加密，有现有的成熟解决方案HTTPS即可
2.  JSON报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好
3.  语言无关，各大热门语言都提供了成熟的RestFul API 框架，相对其他的一些RPC框架生态更加完整。

[70]: /images/20220509/f44808873561426186d451ce0c4966bf.png
[70 1]: /images/20220509/32275a467e954671be3c30218aedeb0d.png
[70 2]: /images/20220509/70f8a0dcb36c4438ad9a4c11cc2a2d2e.png
[70 3]: /images/20220509/e4e01735c0ad4620b39ed284d66be3b7.png
[70 4]: /images/20220509/457e80ff49114b03b4e339e21da82a74.png
[70 5]: /images/20220509/676b16f8aaf84e46894aadddfcd00900.png
[70 6]: /images/20220509/c43836d320f74b14baaa79d38db2706c.png
[70 7]: /images/20220509/438c8f10979b4df0b73b0aaac6b72846.png
[70 8]: /images/20220509/eda0df39392846d6ae112e819009daf9.png
[70 9]: /images/20220509/ee0012e385374444a4e5aaa26e06ad0e.png