12.当下计算机体系架构与演变的自我理解

经过11月的整理，对当下微服务框架涉及的初步技术有一定的理解。本文中将对自己的了解进行体系化梳理，形成自我认识的计算机系统架构资源。将从硬件优先阶段/软件优先阶段/云服务阶段为主线，进行软件架构的演变进行对比，形成自我认知的体系化梳理。

1.硬件优先期

这个时期经历了非常长的一段时期，从为数据统计形成的电子计数器时开始，到现代操作系统出现，都可以归类为硬件优先时期。这个时期经历了计数器/密码机/冯.诺依曼原型到大型计算机的整个过程。

这个时期，软件是与硬件直接捆绑的。也就是使用特定的编译语言对计算机进行输入的过程。随着计算机体系的发展，形成了较为规范化/统一化的编译语言。这个过程中由大型计算机厂商牵头形成了各自标准化组织。硬件的标准接口在标准化组织的推动下，形成了一系列的集成规范。最终形成了当前分工下不同厂商生产的硬件基本兼容的局面。

标准的机器语言到汇编语言，统一的硬件接口标准，为计算机体系发展奠定了基石。硬件接口标准的形成与不断发展，为计算机的整体发展与协作提供了基石，让计算机硬件的整个产业链有机的结合起来。在标准接口的基础上各自完善自己擅长的部分.....

这时期硬件厂商关注的软件是基于不同基础平台的硬件驱动程序......

2.软件优先期

从最初面向特定机器的语言到进行了指令级抽象的汇编语言的形成，计算机将进入软件优先的阶段。关注点慢慢从硬件转向软件。硬件在各种标准协议的保证下细化分工，按照摩尔定律进入了快车道。这个时期计算机的工具属性在慢慢的扩张，深入到社会分工的各个环节中。

现代操作系统的出现，让软件的价值不断的提高。

软件的目的是操作硬件，为输入信息获取正确的输出数据，让生活进入数字化时代。这个时期，软件中间键不断出现，出现了大量的软件基础中间件厂商。他们在各自关注的领域或为提供基础服务/或为数据存储/或为提供数据处理能力最终形成了数据库中间件/服务容器中间件/专业业务处理中间件/计算机基础辅助设计软件等。

软件应用在现代操作系统与标准基础中间件的加持下，深入到了生产生活的每一个环节。大到航天工程,小到衣/食/住/行/娱乐等各个环节。

3.协同发展期

当网络模型从实验室走向现实社会时，计算机的工具属性得到了进一步延伸，万物互联有了基本条件----通信能力。这时期基于嵌入式操作系统携带标准通信协议组件的设备不断出现在特定的业务场景中，软件/硬件进入了协同发展阶段。核心的目标是为了管理或实现现实生活中的某一述求。

网络解决了通信问题，改变了交换方式，从文字/声音/图像/视频/到各自各样可以在网络中承载的信息都可以得到延伸。数据成为社会生产的必须品，风险也不断在提升。人工智能在软件环境中不断深入到数据提取/数据加工/数据存储/数据推送等环节中，怎么让人工智能为我们提供优质服务而不作恶，是优先考虑的问题，当下标准化组织已有这方面的标准规划.....

数据共享与数据安全成为优先事项，网络安全企业成为这阶段的重点企业，为基础平台提供安全控制。

4.云服务时期

随着应用与软件的不断发展，软件参与社会活动的深入。数据的重要性与规模不断的扩张。传统的单机早已不在胜任，云服务已成为主流架构在生产环境中存在。

什么是云服务时代,看企业高大上,本质是什么呢？

云服务首先是服务，也就是软件化服务，底层支持还是各种硬件，只是这些硬件被软件管理起来了，形成了一份硬件可用清单。由云平台在客户无硬件感知的情况下以软件的方式提供服务。当下的k8s较为火爆,docker等容器技术不断在扩张，云调度平台与硬件容器化服务平台，提供了云服务的核心组件。

硬件还是那些硬件，只是使用软件手段把所有硬件资源进行清单化管理，云平台的最大可用单元为单一计算机，最小单元可用根据业务需求在单机机器中使用容器化技术把单机资源划分为多个容器实例，对外提供虚拟化服务。

软件怎么能管理到硬件呢？

云服务平台不会主动去管理硬件，而是接入云平台的机器必须安装云服务终端代理软件与容器化基础平台。如k8s+docker中，接入云平台的机器必须安装docker与k8s 代理软件.

k8s的节点就是一台物理机或者虚拟机，普工的物理机或虚拟机怎么成为k8s的节点呢？在虚拟机上安装kubelet与kube-proxy,容器应用后进行简单的配置，就可以把相应的机器资源加入到k8s服务平台。

 硬件资源云平台化后，对于后续的应用开发有怎么的影响呢？

在传统的模式下，我们必须在购买的服务器中进行操作系统/运行平台/应用软件的安装部署过程。有了运行容器后，我们在打包应用时，可以直接把应用打包成容器镜像文件。一个容器镜像文件可以在容器中构建多个实例，其中的一个实例就相当于一台虚拟机。所以会加快产品的部署时间。容器会自动根据云管理平台的配置自动完成容器部署与运行控制。

本质变了吗？没有。只是部署方案自动化了。

这样给我们带来了什么好处？

可以实现快速回滚与灰度发布。让我们的运行环境变得更容易把控与快速响应，降低产品更新带来的影响。

有什么不良影响呢？

对于早期团队不友好,因为硬件资源在较为充足的情况下云平台才有优势，如果我们只有几台物理机，并且配置不怎么好？强行云化将得不偿失。

随着管理数据的不断膨胀，硬件的引入必不可少。当达到一定的程度时，进行云化部署是一个非常明智的选择。

5.微服务架构时期

当前行业中，尤其是电商行业，并发量与业务量都急聚攀升。但在整个平台的应用体系中，不同的功能应对的访问压力是不同的，并且基于平台运营需要，会有意引导流向指向特定功能。怎么解决如618/双11这样的大访问量呢？

微服务架构正好满足了这样的需求。微服务是分布式系统架构中的一种形式，把业务服务划分为多个实例，云平台可以根据访问的实时流量，根据预判的规则对特定的实例进行动态收缩，以便把平台管理的硬件资源最大化利用。

微服务架构的核心是统一服务网关/服务注册与发现/中心化配置以及服务治理等内容。

 当前java 方向下，spring cloud提供了微服务相关的基础组件，可以让我们快速实现面向微服务的功能实现。

6.面向领域的架构（低代码平台化）

随着产品的不断发展与提升，集成特定领域知识的软件升华为通用基础组件：如工作流平台/报表平台/权限组件/业务UI设计器等。这些基础组件标准化后被整合成面向业务编排的低代码平台，最终在低代码平台中使用少量的代码扩展能快速实现业务整合，实现企业特定业务的固定。

这是一种双赢的架构模式，客户与供应商之间形成了默契，可以在保证产品质量的前提下快速构建相遇的业务平台。

当前遇到的问题：低代码平台组件的标准没有定义，各平台供应商自成体系，并且缺少组件接入标准，让已有成型的功能无法快速接入。

标准缺失：

在面向领域的架构中，核心是组件的接入接口的定义。编排功能标准化，可编排的业务组件对外开放接入标准。

开发模式：

当我们进行面向领域模型设计业务时，UI前端必须按照对应的低代码平台进行兼容实现，后端业务可以采用微服务模式，让低代码平台能快速接入。

7.我们产品的演化与后续发展

注：部分图片来自网络