分布式架构设计学习笔记——架构演变过程

好久没有写博客了,原因是啥呢?没错,就是懒。不过作为一个程序员学习是不能停止滴,这一系列的笔记我之间都是记录在某笔记软件上的,所以这一系列可能会发的比较快,但是可能有些语无伦次(毕竟都是ctrl+c,ctrl+v)~

总的说起来,服务端架构演变可以表达成这样
mvc垂直架构->rpc远程调用架构->soa->msa

各种架构都曾经红极一时,以下是它们的特点:

  • mvc适合小型项目:所有功能部署在同一进程中,通过双机或者前置负载均衡器来实现负载均衡(前后端不分离)
  • rpc:在垂直应用越来越多时,应用之间的交互不可避免,将核心和公共业务抽取出来(前后端分离)
  • soa:在服务数量增多时,服务的生命周期管理以及运行态的治理成为瓶颈,此时可以使用soa的服务治理
  • msa:随着敏捷开发,持续交付,devops理论的发展,已经基于docker的轻量级容器(LXC)技术的成熟,微服务架构开始流行。主要优点是交付周期缩短,运维成本大大下降。

MVC垂直框架

mvc分为model view control三层。优点在于项目足够小时,开发便捷,成本低。

mvc面临的难点:

  1. 复杂应用的开发维护成本变高,部署效率逐渐降低:代码量膨胀之后打包部署越来越慢
  2. 团队协作效率差:不同团队之间开发重复的api
    系统可靠性变差:当流量过大,引起一个节点崩溃,这个节点的流量会分摊到其他节点从而引起“雪崩效应”。
  3. 维护和定制困难:代码量过多的情况下,对于已有的复杂业务难以进行拆分。有时候改一处代码会引起许多地方报错
  4. 新功能上线周期变长:公共api变更的时候,因为好几个地方都是使用同样的代码,所以需要改很多很多地方,还要测试;新特性不能够单独打包,必须要跟老功能一起打包,新老功能之间耦合性过大。

随着业务增大,mvc应运淘汰。

RPC框架

rpc的技术重点:

  1. 远程服务提供者需要以某种形式来提供服务调用相关的信息
  2. 远程代理对象
  3. 通信
  4. 序列化

rpc面临的问题:

  1. 服务越来越多时,负载均衡的压力变大。此时需要一个服务注册中心来动态的注册和发现服务
  2. 随着业务的发展,服务之间的依赖越来越复杂,耦合性越来越大
  3. 服务的调用量增大,需要增加服务来采集数据,根据此来得出需要加多少机器来满足当前调用量
  4. 服务上线容易,下线难

当业务发展足够大时,可以发现此时需要努力的方向是后端服务拆分(垂直拆分或者纵向拆分);此外,一旦开始服务拆分,服务治理技术也需要开始运用。

SOA(面向服务的架构)框架

soa设计原则:

  • 服务可复用
  • 服务共享一个标准契约
  • 服务是松耦合的
  • 服务是底层逻辑的抽象
  • 服务是可组合的,可编排的
  • 服务是自治的
  • 服务是无状态的
  • 服务是可被自动发现的

soa服务治理是关键点,包括:

  • 服务定义
  • 服务生命周期管理
  • 服务版本治理
  • 服务注册中心
  • 服务监控
  • 运行期服务质量保障
  • 快速的故障定界定位手段
  • 服务安全

soa的生命周期:

  • 计划:确定服务治理的重点
  • 定义:定义服务治理模型
  • 启用:实现并实施服务治理
  • 度量:根据实施效果,改进服务治理模型

soa应该是大部门公司使用的架构。对于中型业务来讲,soa的服务拆分相对比较简单。

MSA 微服务架构

当服务化越来越大,soa面临的服务治理问题越来越大。此时msa应运而生。
微服务的主要特征如下:

  • 原子服务
  • 高密度服务
  • 敏捷交付
  • 微自治

msa与soa的差异如下:

  1. 服务拆分粒度:soa的拆分粒度较大,msa强调原子性,要求粒度尽可能的小
  2. 服务依赖:soa由于需要重用已有的资产,所以会存在大量的服务间的依赖;
  3. 而msa的设计理念是服务自治,避免与其他服务进行过度的耦合
  4. 服务规模:传统soa的服务粒度比较大,多数会采用将多个服务合并打包成war包的方案,所以服务的实例数有限;而微服务强调尽可能的拆分,很多服务会独立部署。这将导致服务数量急剧扩增
  5. 架构差异:微服务化后,由于服务数量的急剧扩增会导致架构质量属性的变化,比如企业集成总线ESB逐渐被P2P的虚拟总线替代
  6. 服务治理:传统基于SOA governance的静态治理转型为服务运行态微治理,实时生效
  7. 敏捷交付:微服务强调敏捷

msa的服务数量远大于soa,量变引起质变。而且msa相比于soa更加适合于敏捷开发的项目管理流程。

你可能感兴趣的:(分布式架构设计学习笔记)