架构的演变
架构的演变
直到目前为止,还有很多同学对"微服务架构"和"中台架构"存在很多疑问,写此文以做探讨
因为专业缘故,本文举例使用以银行系统为例
历史回顾
上古时代(大约2000年以前),没有系统架构的说法,因为系统都很简单,核心系统承担主要功能.所有的功能都在核心系统完成,包含柜面,存款,计息,信贷,计提等等.为了运行那么大且复杂的程序,所以一般需要机器性能非常高,小型机甚至中型机是常见选择.在那个时代,国外无论是HP还是18M,都是风头无量的.
到了2005年左右,18M中有一个聪明的脑袋,想出来SOA架构,是通过soap协议,在公司内部形成ESB(企业服务总线),将原有复杂的应用进行拆分.形成了下面的图.
很显然,ESB的产生对系统结构产生了深远的影响,原本基本单机支持整个系统演变为多机协同支持整个系统.所以在2005年以后,中型机开始退出商业使用,小型机的使用开始受到约束.
当大量系统按照SOA架构开始集成,ESB本身开始出现性能瓶颈,以至于18M开始在power处理器中,增加硬件对xml解析的支持(这也是18M硬件性能更好的一个很重要原因).
2008年,阿里中另外一个聪明的脑袋,想出了服务注册中心的概念,再通过注册中心的注册地址,让客户端和服务端直连通讯,随后这个应用在阿里内部大量使用,最终开源.微服务架构从此而来.
微服务架构
因为ESB成为了性能瓶颈,也因为SOA自身技术选型,选择了SOAP协议,导致无论怎么优化硬件都无法解决的性能问题.最终SOA下的ESB方案被放弃.ESB被放弃的同时,原本挂在ESB下的系统也同时开始分化.业务对系统的要求越来越高,以至于系统必须被拆分(类似SOA对老旧系统的拆分),子系统越来越专业,同时也能提供更好的性能.
这边要特别说明下分布式和微服务的区别
和SOA对老旧系统结构的改造类似,微服务本身的提出,也对原有的系统结构产生了影响.在微服务时代下的系统结构变成了如下图的样子
SOA架构到微服务架构下的演变,带来如下的区别
| 角度 | SOA架构 | 微服务架构 |
|---|---|---|
| 系统粒度 | SOA架构挂载在ESB上,总体上还是以业务系统为边界 | 微服务打破原有的系统边界,拆分通用原子服务 |
| 部署 | 功能聚合,包边界清晰,包内复杂,粒度很粗,很难扩展 | 包内简单,包外复杂,粒度较细,扩展方便 |
| 复用度 | 系统边界清晰,不存在系统间的复用 | 通过抽象通用行为,得到抽象服务 |
| 性能 | 受制于SOAP,性能一般 | 服务功能单一,性能提升 |
另外一方面,在SOA架构下,排布在ESB总线2边线条状的系统结构转变为垂直立体的系统结构.这种立体的结构也不是微服务与生俱来的,而是在长时间的实践中,慢慢转变而来的.这种立体结构,在逻辑上可以理解为依赖关系,在业务上理解为通用操作,还有在部署上理解为启动顺序.
从SOA架构到微服务的变迁,除了带来系统结构的变化,性能提升外和便于扩展外,还带来了大量的副作用.主要的副作用有:
- 在SOA架构体系下,原本为系统内的调用变成系统间调用,本来不存在的事务一致性问题,开始冒出头来.
- 原本ESB上架设的各种管控功能,在微服务体系下,因为缺乏统一的调用入口,而变得非常难以管理.
- 原本系统部署,只操作一个部署包,在微服务体系下,一个系统拆分为N个部署包,运维难度呈现指数级上升.
上述问题分别对应了当前的一些技术热点
| 原由 | 问题 | 技术点 |
|---|---|---|
| 系统内调用变成系统间调用 | 事务一致 | 分布式事务,seaga,LCN |
| 系统内调用变成系统间调用 | 调用管控 | 调用链监控,pinpoint,skyworking |
| 系统内调用变成系统间调用 | 调用管控 | 熔断hystrix,sentinel |
| 运维难度上升 | 部署包变多 | 一键部署,自动化部署,容器部署 |
| 运维难度上升 | 部署包变多 | ELK,日志平台 |
因为性能的大量提升,导致所有压力都在DB上,为了分担DB的压力,又衍生出DB的各种操作,读写分离,分库分表以及分布式数据库.
中台技术架构
2016年,又是阿里有个聪明的脑袋,提出中台技术架构.又是一大堆人在懵.
中台架构和微服务架构的区别到底是在哪边呢??
到目前为止,互联网上没有看到任何关于为了支持中台架构而生产的中间件,所以,有理由相信,所谓的"中台架构",不是一种类似SOA架构->微服务架构那种技术上的转变.那"中台架构"在技术上又是怎么一回事??
很多言论表明,中台架构的提出是为了让阿里能快速响应来自互联网上的挑战,说句人话就是,如果互联网上又新的应用,新的点子出来,我通过已有的内部服务,快速响应,难道还打不死一个从无到有的小应用么??
所以,阿里的中台架构,更多的是在组织层面,成立各种共享事业部,能力中心.
仔细分析阿里内部的各个能力中心,我们也会发现不一样的东西.
- 每个能力中心基本上都有一个核心服务,所谓的"核心服务",是指服务调用的终点,不会再外调,或者某项业务的终结.
- 这种能力中心的边界,和具体的业务边界重合度比较高.某一个能力中心,可以看成为了完成某个业务的一个微服务的系统族群.
有点悲哀的是,人家提出一个中台概念,挂靠技术架构,却完全没有从技术层面来看待问题.直到去年,有消息传出人家阿里开始不玩中台了.不知道前段时间,以技术中台的名义来推系统的各路技术大拿们,你们心里是咋想的?
还有一个点需要单独拿来说说.很多不负责任的软文在大谈特谈中台架构的同时,往往忽略了阿里内部的架构玩法.阿里做为一个巨型互联网集团,内部是有大量的信息交互的.具体的结构是这样的.
拿出这张图的意思,不是为了说明老子多牛逼,而是想告诉当前的人,在SOA技术架构下,ESB是全公司唯一的存在,而在微服务架构下,注册中心不是全公司唯一的存在,而是有层级的,是有多种层级,按照不同的业务要求进行分类暴露.
如果考虑到注册中心的层级,挂在的服务一定是要满足无状态的要求的,这点又和前面"前后端分离和系统安全"扯上关系了.用人话说就是,挂在注册中心上,能被调用的服务,必须是无状态的.