技术架构的演进之路：为什么需要微服务？

妖狐艹你老母 2022-12-28 00:39 307阅读 0赞

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-263T5MU7-1607762238687)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/02687087c936444685bbedf872fbd524~tplv-k3u1fbpfcp-zoom-1.image “技术架构的演进之路.png”)\]

# 整体发展概览 #

服务架构一直处于演变之中，为了适合自己的业务，不断的去调整。

整体的发展历程如下：

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2A3kYqAx-1607762238692)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c9b8ea41b2d847fa8ca9dab38938c330~tplv-k3u1fbpfcp-zoom-1.image “屏幕截图.png”)\]

# 开发者视角 #

从一个 java 开发者，感受大概经历了下面几个历程：

## 第一阶段：单体架构 ##

早期，大部分IT系统都是单体系统，例如传统的SSH架构，此时前后端也没有分离，UI组件也包含在了控制层：

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SinbZhgW-1607762238695)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/22f0b5d4ecd54449b932617e8d039b9a~tplv-k3u1fbpfcp-zoom-1.image “屏幕截图.png”)\]

这个也就是老马刚毕业时候的架构，SSH 基本是面试必问。

不过现在这些都发生了一些变化，主流已经变成了 spring mvc + spring contaienr + mybatis。

只能说，spring，java 界永远的春天！

## 第二阶段：分布式架构 ##

为了方便给系统扩容，以及增加系统的复用性，出现分布式系统。

另一方面，系统模块快速膨胀，为了降低系统内部的复杂度，于是对系统模块进行拆解，分不到不同的系统中，降低模块耦合，加快迭代速度。

ps: 其实主要是降低单个应用的复杂性，让每一个应用专注于一件事情。这样可维护成本大大降低，换言之，开发完后以后，可以让一个刚毕业的新人做运维。把开发者裁掉，降低成本。

主流主要是 SOA 和 MSA 两种体系。

### SOA ###

早期的分布式系统是基于面向服务的架构SOA。

SOA是微服务的前身，主要是为了摆脱单体应用的问题，达到以下效果：

1.  充分利用现有的基础设施；
2.  SOA体系结构依赖于消息传递（AMQP，MSMQ）和SOAP作为主要的远程访问协议。
3.  快速响应业务变化；

架构图如下：

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0O25hm6u-1607762238700)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9985ed00fe9848b6b597bbddf8649e57~tplv-k3u1fbpfcp-zoom-1.image “屏幕截图.png”)\]

异构系统，也可以通过消息中间件的协议转换进行相互调用。

这个我倒是接触过一段时间，当时业务系统是 C\# 开发，我所在的后端服务使用的是 java 技术开发。当时的协议使用的是 webservice。

但是用起来感觉不是很顺畅，主要缺点如下：

（1）WebService中常用的SOAP通信协议，通常使用XML格式进行通信，数据冗余，协议过重

（2）服务治理很不完善。

后来逐渐演变为了现在的 **MSA（Micro-Service Archeticture 微服务架构）**，从而实现了更加松耦合以及更加灵活的系统。

### MSA ###

微服务是一种软件开发技术——面向服务的体系结构(SOA)体系结构样式的变体，它将应用程序构造为松散耦合服务的集合。

在微服务体系结构中，**服务是细粒度的，协议是轻量级的**。

*  微服务架构图示

![微服务架构图示][eb0c899da7cfe5801c5e10e78080138f.png]

## 优点 ##

微服务架构有很多重要的优点。

首先，它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变，但应用程序已被分解为可管理的模块或服务。

这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平，而这通过单体代码库很难实现。

因此，微服务开发的速度要快很多，更容易理解和维护。

第三，微服务架构可以使每个微服务独立部署。

最后，微服务架构使得每个服务都可独立扩展。

现在这种架构模式已经成为主流，个人感受最深的就是如果你只负责单一服务，你可以把他理解的比较透彻，而且维护起来也没有那么复杂。如果有功能变更，只上线对应的应用即可。

## 缺点 ##

微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。

*  运维开销及成本增加
 *  必须有坚实的 DevOps 开发运维一体化技能
 *  隐式接口及接口匹配问题
 *  代码重复
 *  分布式系统的复杂性
 *  异步机制
 *  可测性的挑战

个人感觉微服务最大的问题在于系统的拆分之后，很难有一个人可以知道系统的全貌，所以定位问题变得非常复杂。

举个例子，如果交易发生一笔失败，你可能要从API网关=》业务系统=》交易核心=》支付核心=》风控系统问一遍才能知道原因，最后发现是对底层的系统返回了一个失败，这里涉及到多个系统的沟通成本，基本上半天的时间就没了。

## SOA vs 微服务 ##

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-62orc1X1-1607762238706)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d6a997a5c5d4457fac55be4c6df846ef~tplv-k3u1fbpfcp-zoom-1.image “soa.png”)\]

<table> 
 <thead> 
  <tr> 
   <th align="left">SOA</th> 
   <th align="left">微服务架构</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">应用程序服务的可重用性的最大化</td> 
   <td align="left">专注于解耦</td> 
  </tr> 
  <tr> 
   <td align="left">系统性的改变需要修改整体</td> 
   <td align="left">系统性的改变是创建一个新的服务</td> 
  </tr> 
  <tr> 
   <td align="left">DevOps和持续交付正在变得流行，但还不是主流</td> 
   <td align="left">强烈关注DevOps和持续交付</td> 
  </tr> 
  <tr> 
   <td align="left">专注于业务功能重用</td> 
   <td align="left">更重视“上下文边界”的概念</td> 
  </tr> 
  <tr> 
   <td align="left">通信使用企业服务总线ESB</td> 
   <td align="left">对于通信而言，使用较少精细和简单的消息系统</td> 
  </tr> 
  <tr> 
   <td align="left">支持多种消息协议</td> 
   <td align="left">使用轻量级协议，例如HTTP，REST或Thrift API</td> 
  </tr> 
  <tr> 
   <td align="left">对部署到它的所有服务使用通用平台</td> 
   <td align="left">应用程序服务器不是真的被使用，通常使用云平台</td> 
  </tr> 
  <tr> 
   <td align="left">容器（如Docker）的使用不太受欢迎</td> 
   <td align="left">容器在微服务方面效果很好</td> 
  </tr> 
  <tr> 
   <td align="left">SOA服务共享数据存储</td> 
   <td align="left">每个微服务可以有一个独立的数据存储</td> 
  </tr> 
  <tr> 
   <td align="left">共同的治理和标准</td> 
   <td align="left">轻松的治理，更加关注团队协作和选择自由</td> 
  </tr> 
 </tbody> 
</table>

## 挑战 ##

微服务的挑战可以概述如下：

*  API Gateway
 *  服务间调用
 *  服务发现
 *  服务容错
 *  服务部署
 *  数据调用

![PatternsRelatedToMicroservices][]

不过幸运的是，很多成熟的中间件，已经为我们解决了这些问题。

# 第一代微服务框架 #

## dubbo 的架构 ##

[Dubbo][] 的架构如下：

![struct][]

dubbo 针对 rpc 这部分做的很好，单也仅此而已。

但是为什么还是会这么火爆呢？

很多架构的升级都会有历史包袱，除非你是一家新公司，全新的应用。

大部分的应用都是 spring 或者 springboot 的，所以现在大部分公司都是 springboot + dubbo 的技术选型方案，这样可以让架构的平滑的迁移。

如果你们公司是全新的技术选型，可以考虑 spring cloud。

## spring cloud 架构 ##

[Spring Cloud][] 架构如下：

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hmWg0fN0-1607762238711)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c5ed80d238fd45a18341c2c6fc352fd6~tplv-k3u1fbpfcp-zoom-1.image “屏幕截图.png”)\]

你会发现 spring cloud 可以说是 java 技术栈中，比较完善的微服务框架。

当然，spring 再牛，负责的声明周期也只是 jvm 之内，应用的部署运维也是需要考虑的。

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GfYvynBk-1607762238713)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/aaf7f9cd310e4dafb1126d1811cd459e~tplv-k3u1fbpfcp-zoom-1.image “屏幕截图.png”)\]

每一项技术都有其优势和局限性，所以需要结合使用。