从单体到微服务—系统架构进化分析

系统架构概览图

1、单一应用架构阶段

当网站的访问量/流量很小的时候，业务上我们把所有的功能（假设有订单、商品、支付、库存…）全放在一台服务器上就可以了

• 注意：这时的系统可能是把数据库、Web服务啥的都部署在同一台服务器上；且也没有什么前后端分离的概念（ JSP 既负责页面展示而且也包含业务逻辑处理代码）。
• 优点：可以减少部署的节点和成本；
• 缺点：扩展性太差，因为前后端代码耦合在一起，维护起来很困难。
• 性能上可以支撑：1-10个并发。
• 代表技术：JSP、Tomcat

2、垂直应用架构（MVC）

• M【Model】 层代码主要存放的是业务逻辑；V【View】 层主要存放的是视图（html、jsp等等）；C【Controller】 层代表是控制层，是处于于M和V中间的一层，用户通过操作V层发送的请求经由V层分发到M层进行逻辑处理。V层逻辑处理的结果通过C层响应给V层，进而反馈给用户。

• 优点：由于代码进行分层，所以扩展性相比于单一应用得到了大大的提升，且将数据库与web服务器分开部署，提高了系统的可用性。

• 缺点：此时的系统仍然只是一个单体应用，因为是在代码层面上的拆分，所以被称之为垂直拆分。

• 性能上可以支撑：10-1000个并发

• 代表技术：JSP + Servlet + JavaBean；SpringMvc等等

3、分布式服务架构（RPC）

当垂直应用（每个应用都是MVC架构）越来越多，应用之间的交互不可避免，这时就将核心业务抽取出来，作为独立的服务：

• RPC：Remote Procedure Call，远程过程调用，调用远程服务器上的函数或者过程（最初是针对C语言这样的面向过程的语言提出的概念）就跟在本地调用一样，要实现RPC需要解决三个问题：

  1. 通讯问题：RPC的通讯需要依赖于某种传输协议（比如：TCP、UDP）。
  2. 寻址问题：你怎么找到远程服务器【ip】，怎么找到远程服务器上的哪个服务【端口】，怎么找到具体要调用哪个方法【方法名称】。
  3. 序列化和反序列化：因为网络协议是基于二进制的，想要通过网络传输，首先发送方得把数据转为二进制数据【序列化】。然后接收方需要把二进制数据进行一个恢复【反序列化】。

• 优点：原本部署在一个服务器上的多个业务，都拆分到了独立的服务器上，彼此之间通过RPC框架来进行通信；且此时有了多个数据库。

• 缺点：随着服务越来越多，在本服务需要维护其他服务的信息（如：ip、端口…）越来越多，管理这些信息的方式不够灵活。

  举个例子：假如订单服务需要调用库存服务，这时我们需要拿到库存服务的 ip + 端口 才能在互联网中找到对应服务器上的对应服务。

  那这些 ip + 端口 的信息直接写死在代码里面吗？这样的方式不够灵活，且万一服务的 ip、端口信息有变，就得去修改代码，一两个地方还好，地方一多起来，你可能会想骂娘。这种方式显然不符合开闭原则，所以你可能会想到使用配置文件来记录这些信息可能会更好。但是，每次新加一个服务你仍然得去修改这个配置文件，显然还是差点意思。
  

4、流动计算架构（SOA ）

SOA 出现背景（why？）

当服务越来越多，容量的评估，小服务资源得浪费等问题逐渐显现，此时需要增加一个调度中心基于访问压力，实时管理集群容量，提供集群利用率。服务生命周期的管控和运行态得治理成为瓶颈。

此时，用于提高机器利用率的，提升服务质量的（资源调度和治理中心）SOA 服务治理是关键。

SOA 是什么（what？）

SOA：Service Oriented Architecture ，面向服务架构。

ESB：Enterprise Service Bus，企业服务总线，也被称为服务中介。主要是提供了一个服务用于服务之间交互。简单来说 ESB 就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通。

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

SOA 架构的特点

1. 系统集成：有序的解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构。
2. 系统的服务化：站在功能的角度，把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。
3. 业务的服务化：站在企业的角度，把企业只能抽象成可复用、可组装的服务；把原先只能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力。

5、微服务架构

微服务出现背景（why？）

微服务是在 SOA 上做的升华，微服务架构强调的一个重点是业务需要彻底的组件化和服务化，原有的单个业务系统会根据业务拆分成多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

微服务其实就是一个轻量级的服务治理方案。

微服务是什么（what？）

微服务架构是一种架构模式，他提倡将单一应用程序划分成一组小的服务，服务之间互相协调，互相配合，为用户提供最终价值。

每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 协议的 Restful API）。

每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境。另外，应当尽量避免统一的、集中式的服务管理机制。对每一个具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其构建。
在这里插入图片描述

微服务架构特点

优点：随着敏捷开发、持续交付、DevOps 理论的发展和实践，以及基于 Docker 等轻量级容器部署应用和服务的成熟，微服务架构开始流行，逐渐称为应用架构的未来演进方向。通过服务的原子化拆分，以及微服务的独立、打包，部署和升级，小团队的敏捷交付，应用的交付周期将缩短，运营成本也将大幅下降。

特点：

• 通过服务实现组件化，开发者不再需要协调其他服务部署对服务的影响。

• 可以按照业务能力来划分服务和开发团队，开发者可以自由选择开发技术，提供 API服务。

• 去中心化，每个微服务都有自己私有的数据库持久化业务数据，每个微服务只能访问自己的数据库，而不能访问其他服务的数据库。

  某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其他微服务的数据库，而是通过对于微服务进行操作。

  数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。

• 基础设施自动化（devops、自动化部署）

把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖于任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于 HTTP 资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多啦，不集中管理就无法DevOps啦）。

参考引用

参考博客：https://www.iteye.com/blog/maosheng-2434993
Dubbo官网：Dubbo官网

---

我是杰哥，一个在IT行业中正在不断学习的程序员。 欢迎各位说话好听的人才们一键三连，你们的支持是我更新的最大动力，咱们下期见~

文章持续更新，可以微信搜索「 杰哥是真想教会你 」第一时间阅读，回复【面试】有我准备的一些在精不在多的面试资料。