拜特科技资金管理系统运维变迁之路

　　引子
　　2000年拜特科技成立，到今天已有22个年头，这二十几年来信息化技术可谓突飞猛进，日新月异，拜特科技作为专业的资金管理软件服务提供商，紧跟技术潮流，产品一路迭代升级，从C/S架构到B/S架构，从Web/Sevice到践行SOA，如今又迭代升级到业界流行的微服务架构。今天这篇文章，将以一个运维工程师的视角来跟大家一起梳理一下这20多年来，承载系统运行的环境也就是我们常说的＂计算机＂这一路走来经历哪些变迁。
　　本文核心关键字：C/S架构模式、B/S架构模式、微服务架构、虚拟化、容器
　　一、C/S架构-物理机的年代
　　拜特科技资金管理系统第一个版本是C/S架构，是由公司创始人胡德芳先生开发，这个版本为公司带来了前期核心的几十家客户，也奠定了拜特科技成立的基础。下图是当年C/S架构系统的一个截图，现在回头看，满满的年代感。
　　C/S模式，即Client/Server或客户/服务器模式，是服务器客户端结构。是一种＂一对多＂的模式，一台服务器，处理多个客户端发来的请求，完成了业务逻辑之后，再返回给客户端一些信息。
　　C/S架构下，数据库一般部署在实体机上，大型客户一般在IBM P系列小型机或者SUN SPARC工作站上，记得当时第一次操作IBMP系列的小型机，就被它强劲的性能和敦实的外观深深的吸引（当然服务器价格也很强劲），在服务端，系统部署简单，数据库安装部署好即可，工作量也不大，由于客户端需要单个安装，就需要到客户各个工位，楼上楼下的跑了，通常安装完毕，大半天就过去了。
　　C/S模式下，更多依赖＂垂直扩展＂，性能出现问题，基本上就是简单的硬件升级，在运维层面，更多的就是帮助客户迁移数据库，重新升级系统。
　　二、B/S架构-日益丰富的企业应用
　　时间来到2006年，拜特科技的产品架构也迎来了B/S架构模式，应用服务，第三方接口服务，银行接口平台服务也需要独立部署，用户客户端不用直连数据库，所有的交互式业务操作都直连应用服务完成，在部署上，需要专门的应用服务器，第三方接口服务器，银行接口服务平台服务器。简单结构图如下：
　　B/S架构模式，系统的安装部署就省心很多了，一般情况下数据库服务器跟应用服务器都在一个机房，之前的服务的央企客户都有比较完善的机房，一进机房，机器风扇发出的嗡嗡声和寒气逼人机房制冷空调，扑面而来，老实说在机房作业并不是一件令人愉悦的事情，好在安装运维工作在企业的机房就能完成了，时间也不会太久，至少省去了之前爬高上低的辛苦。
　　进入B/S架构时期，企业信息化程度已经大大向前，加上中心化的部署，为了系统的高可用，也需要冗余部署，所需要的服务也越来越多，如果只在单台服务器部署一个应用服务，所需要的服务器也非常多，实体服务器过多带来的挑战越来越大，具体问题如下：
　　● 基础架构利用率低；
　　● 基础架构成本高；
　　● IT运维成本高。
　　那么能否将多个应用部署到一台实体机器上呢？理论上这样做是可以的，但是多应用部署到一台机器，就会存在资源相互影响的问题，例如A应用存在bug，造成了内存泄漏，B应用就会被连累遭殃，那么如何在充分利用机器资源的情况下，又能避免相互影响的问题呢？各个底层应用的厂商开始了新的探索。
　　三、虚拟化技术-真真假假的世界
　　虚拟化技术是底层应用厂商对实体机资源管理的一种优化技术，通过将计算机的各种物理资源（如CPU、内存以及磁盘空间、网络适配器等 I/O 设备）予以抽象、转换，然后呈现出来的一个可供分割并任意组合为一个或多个（虚拟）计算机的配置环境。
　　虚拟化技术打破了计算机内部实体结构间不可切割的障碍，使用户能够以比原本更好的配置方式来应用这些计算机硬件资源。而这些资源的虚拟形式将不受现有架设方式，地域或物理配置所限制。
　　IBM最先推出虚拟化产品，在资金系统中，P系列小型机是使用的虚拟化产品，但是由于成本原因，只能在大的集团企业中使用，使用广度不够。随之VMWare公司基于X86架构虚拟化产品的发展，虚拟化硬件资源在资金系统使用得到了广泛的应用，已经占现在系统部署的绝大多数，虚拟机架构体系如下：
　　四、微服务架构-一起太挤各自放飞
　　通过虚拟化技术后，之前的一个实体机被虚拟成多个虚拟机，既能充分的利用机器的计算资源，又能很好实现应用之间的隔离，看起来一切都很美好，但是在微服务架构模式下，虚拟机模式又迎来了新的挑战。本文重点不是介绍微服务的，以下只是举一个例子简单说明下问题所在：
　　马丁、福勒：2014.3.25: https://www.cnblogs.com/woshiyourenM/p/14579451.html 第一次系统性的对微服务架构的阐述。
　　如上图之前微服务架构之前，拜特科技的资金系统整体是ALLINONE模式，实际部署的时候，一个tomcat容器就能正常部署，微服务拆分后系统按细分领域被划分成多个子系统，每个子系统单独部署。微服务后需要部署的单元大大增加，整个运维与部署的工作量也显著增加，如果我们用虚拟机为单位来实现应用的部署与隔离，就遇到了新的问题，虚拟的创建与运行需要占用大量的系统资源，面对快速扩张的部署单元需求，需要新的技术来支撑。
　　五、Docker容器-人微言不轻
　　与虚拟机相似的地方，docker也实现了计算机各种资源的虚拟与隔离但是相对于虚拟机模式具体的底层实现原理确有着本质的不同。通俗的讲容器技术相对于虚拟机的优势可以用＂多、快、好、省＂四个字来概括。
　　虚拟机和容器的一些对比：
　　使用容器化部署的优势：
　　● 提高硬件资源使用率。
　　● 一次构建，到处运行，跨云和操作系统发行版本的可移植性。
　　● 保证开发、测试和生产的环境一致性。
　　● 为应用程序提供更快的创建和部署。
　　● 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），提供可靠且频繁的容器镜像构建和部署。
　　● 资源隔离：可预测的应用程序性能。
　　提供容器化的产品有很多（docker/podman/cri-o/containerd 等），但最有名非Docker莫属 。下面是CNCF推荐的一些容器运行时产品介绍：
　　采用docker镜像部署后，以前安装系统需要的长长的安装说明就基本上不需要了，简单的几行命令，一个新的环境就轻松搞定，回想起，当年安装一个应用jdk，tomcat，应用各种拷贝，现在居然还有一丝丝的怀念，运维这个工作曾经的脏活累活也由因为技术的进步逐渐退出历史舞台，不由的感慨＂科学技术是第一生产力＂。
　　六、容器编排（k8s）-运筹帷幄
　　虚拟化时代，当虚拟机的数量达到一定量级的时候，单个去管理虚拟机简直就是一个灾难，所以便诞生了像 openstack 之类的系统，可以大批量的管理虚拟机，运维人员只需要通过web界面或CLI就可以管理成百的虚拟机。
　　同样，容器化时代，当容器的数据达到一到量级的时候，容器编排系统也随之诞生了。其中 kubenetes是容器编排系统中最有名的（没有之一），它已经是事实上的容器编排标准。
　　k8s能做什么？
　　● 自我修复：你不需要去手动的重启已经挂的程序，k8s会自动帮你重启。
　　● 自动分配CPU/内存资源：可以直接给程序提前分配它所需要的硬件资源。
　　● 自动部署和回滚：自动把你的程序部署，也可以自动回滚你的程序到之前的版本。
　　● Secret和配置管理：k8s可以管理机密信息，而不用把机密信息暴露到集群外。
　　● 存储编排：可以添加任何本地或云厂商提供的存储产品。
　　● 服务发现和负载均衡：k8s已经实现服务发现和负载均衡功能。
　　● 项目实战：借助k8s，运维人员通过控制台，就能像坐在中军帐的诸葛亮一样，对机器的资源运筹帷幄了。
　　后记
　　一路走来，借助系统架构的演变与计算资源的虚拟化，从C/S架构时代爬上爬下的安装应用，一次部署就要忙碌大半天，到如今借助web管理控制台，轻轻松松，完成机器资源的申请，扩容，缩容，一键应用程序安装，真心感叹人类伟大的创造力与创新精神，作为业务系统提供厂商，拜特科技也衷心希望能通过我们的系统迭代升级，功能的完善能给我们的客户在业务支撑上提供更多的惊喜，一路向前，感恩客户，加油拜特科技!