系统架构篇:传统架构和中台架构的辨析

声明:本文非专业技术文章,重点在于通俗易懂。

一、传统架构和中台架构

1. 中台和PaaS的关系

先辨析下中台系统和PaaS系统的关系:

  • 从外部视角看:中台系统可以是SaaS系统也可以是PaaS系统,但是PaaS系统肯定使用中台系统的架构。
  • 从内部视角看:中台系统是改变了企业的组织架构和服务之间的组合关系。终端客户,感受并不直观。

2. 传统架构和中台架构的结构图

系统架构篇:传统架构和中台架构的辨析

本图是传统系统架构和中台系统架构的简略示意图。

两者共同点和差异点为:

  • 都在虚拟机上运转,传统架构一般在一个虚拟机上运转,如设备算力不足,只能人工干预,部署新的服务。中台系统部署在容器系统中,一般是Docker系统,Docker系统支持自动拓展虚拟机数量,无需人工干预。
  • 都依托内部子服务对外提供功能,传统系统的子服务按照业务逻辑直接组织,内部层级混乱,拓展困难,无法实现针对性的算力拓展,如:只给服务1及其关联对象拓展5倍的算力,而不相关的服务不拓展。中台系统可以实现该功能。
  • 都可监控系统运行数据,传统系统一般在一个虚拟机上运转,直接使用虚拟机自带的工具集基本可以满足要求。中台系统的数据监控平台可以监控所有自动拓展的虚拟机,并能细颗粒度的干预系统运行。可以叠加预警机制和其他业务管理工具。
  • 都可以对系统干预,传统系统干预手段单一,比如:关机、重启。中台系统干预手段丰富,包括限流、预警等。
  • 中台系统微服务复用效率更高。
  • 都对外提供服务,由于以上优点,中台系统用户体验更好。
  • 中台系统的缺点是:系统复杂,开发周期长。如果企业业务没有复杂到一定程度,可以根据需要部分上线中台系统,逐步完善,无需急于求成。

本节剩余内容对部分模块详细展开:

3. 虚拟机及虚拟机管理

此处的虚拟机并不是狭义上的Java虚拟机,而是广义上的虚拟机。

现代计算机包括输入设备、输出设备、控制器、计算器、存储器五个模块,无论这些设备是直接的硬件实现或者建立在硬件之上的虚拟机如Java、Python等,都属于此处的虚拟机。

传统的框架,设计的计算机程序,都默认在一台虚拟机上运行,当时的计算需求相对较少,一台计算机能提供的算力能满足绝大部分的计算需要。大部分情况下,计算机的算力远远超过了用户对算力的需求,所以当时的思路主要集中在如何实现分时共享,所以诞生了分时操作系统。

随着互联网的发展,各行各业都开始实现互联网 ,此时单台虚拟机算力不够的事情才开始凸显。比如春节抢票,几亿人几乎在同一时间点涌向12306,12306系统忽然产生巨大的计算需求,系统刚上线时,系统无法及时响应用户体验较差(这是以前,现在体验已经很不错了)。正是这种类似的需求催生了中台系统。

4. 服务

之前的文章提到过,抽象的说:

  • CPU的加法器、减法器等硬件实现的计算功能就是服务。
  • C语言的函数将计算器和变量包装到函数体里也是服务。
  • 面向对象的语言,是将多个函数和属性包装到对象里,也是服务。
  • 面向中台的编程,是将多个对象包装到一个docker里,多个docker在docker管理器的支撑下完成业务,也是服务。

所以服务一直都是存在的,只是在传统架构里,各种服务并没有装到相同类型的容器里,所以无法区分操作。

面向中台的编程则是将不同的对象打包到相同类型的多个容器里。通过Docker管理器可以实现仅对某些服务定向拓展或定向关闭。

5. 数据监控

a. 建模和监控的关系

系统设计需要先建模,建模就是使用接口、类图梳理出不同的对象以及对象之间的关系,类图相当于该系统的静态地图。图中标识了哪些是高山、湖泊、河流、农田,他们相互之间的关联关系。

数据监控就是监控不同的数据在这个地图上是如何流动的,轨迹是什么。没有数据监控就不知道静态的地图哪里需要调整,哪条河需要清淤、什么时间容易涨水、哪个路需要加宽等等。

b. 传统模型的监控需求

在计算量需求不高的时候,对数据监控的关注度并不高,只有在系统运行故障时,才需要还原轨迹,用以帮助定位问题节点。

传统的架构,程序和数据在固定数量设备上运转,运算量足够,所以数据监控的重要性并未凸显,但是当系统用户越来越多时,就容易出现堵塞,就需要人工干预。

道理十分简单,很多村道只有一个车道,路口也不安装红绿灯,很少发生交通事故,主要就是因为流量小。但是大城市的道路大部分是四车道或更多,不仅安装红绿灯,高峰时期交警同志还需要上岗执勤,就是因为流量太大,容易出现问题。

c. 中台系统的监控需求

在中台系统中,系统会自动记录每个对象及其依赖对象的创建时间、数量、内存占有率、CPU占有时间等。并能用可视化的方式将信息呈现给技术运维。

d. 两系统对比

传统模型能不能监控数据呢?

当然能,无论是哪个语言都有机制查看对象的运行轨迹,但是当一个业务启用2个、3个甚至更多虚拟机的时候,逐个查看以判断问题,效率就太低了。

并且PaaS平台的数据监控不仅是显示数据,还需要叠加预警机制、干预机制。比如:扩增虚拟机的数量、关闭非紧急服务以释放算力、限制访问、限制流量等等都可以基于数据监控采取干预措施。

6. 干预平台

图中传统架构使用的是干预命令、中台架构使用的是干预平台。

从名字上就可知,中台架构对干预的手段做了极大的升级。

传统的方式最常见的方式就是停机、重启,中台架构不仅支持停机、重启、还支持限流、拓展算力、关闭虚拟服务。并且允许拓展干预指令定时执行等,干预平台实际上是传统架构的干预命令的升级版。

7. 服务平台

服务平台指的是服务用户的平台,包括PC系统、APP系统、智能硬件设备、物联网设备等,两个架构对用户而言,用户可能感觉不到太大的差异,但是实际上中台系统有很多优点:

a. 系统开发更快

按照中台架构设计的系统,系统原有的服务容易复用,传统架构的方式难以实现复用。

传统架构的复用可能主要体现为代码的复用,拷贝、粘贴、调试,基于中台系统的架构无需对原有服务拷贝、粘贴,可直接复用,所以开发周期更短。

系统延伸性强,如果延伸到可视化设计和流程搭建,可以将设计任务转到到非技术人员手中。

b. 系统服务更稳定

中台架构是自动延伸的架构,可以随着访问量的增加,自动拓展资源,自动拓展的硬件资源可以是一台、十台、百台、千台,只要系统本身够健壮,用户可以获得更好的服务体验。

比如12306上买票,大家现在的购票体验,肯定比系统刚上线的时候好很多,基本没有被阻碍的感觉了。

c. 平台更智能

平台在保证自动延伸的前提上,数据并没有分散,还是可以统一访问,为数据挖掘提供了便利,可以使平台更智能。

d. 拓展性更强

更强的拓展性体现在两方面:

  • 硬件拓展性:基于IAAS平台,可以动态扩充硬件资源而不影响系统稳定性。
  • 软件拓展性:方便增加新的微服务,比如部署用户画像系统、用户推荐系统等。

二、两种架构的拓展缘起

为什么要从传统架构升级到中台架构,我们可以从以下设想的场景中推演:

声明:下文只是以12306系统举例子,仅是推演。

设想:12306火车购票系统上线了,春节高峰期,有两亿用户同时访问本系统。虽然事先已经做了预案,但是客户访问量还是超过了预期,此时你应该用什么技术手段应对哪?

系统架构篇:传统架构和中台架构的辨析

1. 现状

系统基于传统架构设计,已提前预估了可能的访问量,并采取了对应的技术措施。

但是系统访问量还是远远超过了预期,如何解决?

  • 立刻改系统来不及,并且如何改,使用什么方案还不清楚。
  • 只能启用临时方案

2. 解决方案

方案至少有三个:

  • 方案一:多次放票,尽量不让访问需求集中在同一时间,错峰放票。(不展开)
  • 方案二:直接拓展硬件,比如加CPU、加内存,该方法有上限。实际执行有哪些限制,需要IT部门评估可行性。(不展开)
  • 方案三:再部署一套或两套独立的系统、独立的数据库。然后使用IP地址的路由技术实现:购买京广线的用户访问后台访问系统A,购买京沪线的用户访问系统B,购买其他路线的用户访问系统C。

最简单的是方案三,该方案可以解决本次问题,但是产生以下新问题:

a. 哪条线路的用户量和哪个系统能提供的计算量最匹配,没有实时的数据依据。

b. 系统不能自动切换,需要人工介入,人工响应慢。人工操作的时间=人反应的时间 机器响应时间。

c. 人工割裂的系统虽然能临时满足购票需求,但是导致数据割裂。导致很多与数据相关的服务无法拿到完整数据。

3. 根本方案

根本方案就是上云,并做中台系统改造:

a. 基于IAAS系统部署,可以动态扩展运算能力。每次新增的算力单位是一个虚拟机,因此虚拟机上运行的需要是具体的微服务,不能整体拓展。

b. 对微服务需要有管理平台,监控服务运行,并能提供干预。

三、服务平台拓展

服务平台有哪些可行的拓展,下文仅展开三个。

1. 可视化设计

产品经理最常使用的工具,肯定是Axure,使用Axure以及积累的元件母版,可以快速的在界面上画出:列表、单选框、复选框、菜单等等各种元素,可以使用动态面板或页面组织这些元素。

中台系统的可视化设计,就是将Axure的组件构建能力移植到Pass平台上,产品经理或者客户可以直接在Paas系统做设计。

PaaS平台的可视化设计比Axure设计的优势为:

  • 可视化平台界面元素都已关联真实数据,无需使用Axure的中继器做数据模拟。
  • 可视化平台的字体、颜色可以被预定义,保证了不同用户设计的风格一致。Axure不做限制,每个用户的设计风格可以不同。
  • 可视化平台的菜单、跳转等框架可以被预定义,用户只需关注界面交互逻辑。相当于在Axure原型的基础上调整,而不是重新构建新系统。
  • 可视化平台搭建的系统,搭建完成后可以直接交由测试,无需技术重新开发。

实际使用时,可视化设计可能会有各种各样的限制,这取决于Pass系统的设计特点和成熟度,理论上可以代替大部分的Axure功能。

2. 流程搭建

产品经理梳理业务常用的流程工具,包括 Visio、ProcessOn、Plantuml等,这些工具做出的流程图与Axure有个类似点,就是与业务系统并不直接联动。

可以将流程搭建的功能集成在PaaS平台上,与传统流程工具相比的特点为:

  • 优势:流程搭建器已关联真实业务对象,通过该工具可以直接组织业务对象的功能和动作,开发周期短。
  • 劣势:流程搭建器,约束更多,自由度低。

3. 叠加人工智能工具

传统方式做AI研究获取数据集的方式包括:excel表格、数据库直接获取、压缩包,然后使用Python自带的数学模型工具做研究。

PaaS平台上获取数据集的方式更简单,直接简单指令就可以获取平台上所需的数据集,并且可以对潜在的数据模型做包装,业务人员使用包装后的工具会比直接使用Python工具效率更高。

平台也支持集成Python工具,对新的模型允许使用Python工具直接计算。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部