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

系统架构概览图

1、单一应用架构阶段

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

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

2、垂直应用架构&＃xff08;MVC&＃xff09;

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

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

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

• 性能上可以支撑&＃xff1a;10-1000个并发

• 代表技术&＃xff1a;JSP &＃43; Servlet &＃43; JavaBean&＃xff1b;SpringMvc等等

3、分布式服务架构&＃xff08;RPC&＃xff09;

当垂直应用&＃xff08;每个应用都是MVC架构&＃xff09;越来越多&＃xff0c;应用之间的交互不可避免&＃xff0c;这时就将核心业务抽取出来&＃xff0c;作为独立的服务&＃xff1a;

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

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

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

• 缺点&＃xff1a;随着服务越来越多&＃xff0c;在本服务需要维护其他服务的信息&＃xff08;如&＃xff1a;ip、端口…&＃xff09;越来越多&＃xff0c;管理这些信息的方式不够灵活。

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

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

4、流动计算架构&＃xff08;SOA &＃xff09;

SOA 出现背景&＃xff08;why&＃xff1f;&＃xff09;

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

此时&＃xff0c;用于提高机器利用率的&＃xff0c;提升服务质量的&＃xff08;资源调度和治理中心&＃xff09;SOA 服务治理是关键。

SOA 是什么&＃xff08;what&＃xff1f;&＃xff09;

SOA&＃xff1a;Service Oriented Architecture &＃xff0c;面向服务架构。

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

ESB 包含的功能如&＃xff1a;负载均衡&＃xff0c;流量控制&＃xff0c;加密处理&＃xff0c;服务监控&＃xff0c;异常处理&＃xff0c;监控告急。

SOA 架构的特点

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

5、微服务架构

微服务出现背景&＃xff08;why&＃xff1f;&＃xff09;

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

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

微服务是什么&＃xff08;what&＃xff1f;&＃xff09;

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

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

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

微服务架构特点

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

特点&＃xff1a;

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

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

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

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

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

• 基础设施自动化&＃xff08;devops、自动化部署&＃xff09;

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

参考引用

参考博客&＃xff1a;https://www.iteye.com/blog/maosheng-2434993
Dubbo官网&＃xff1a;Dubbo官网

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