【51CTO.com原创稿件】
导语：CTO训练营第二季已经圆满收官，作为一个学习分享和社交的平台，CTO训练营提供的不光是知识分享，还有一个属于技术管理者的人脉圈子。结课之后，第二季学员提交了毕业设计，来对四个月以来的学习进行总结与回顾，部分论文由CTO导师进行点评和打分。
技术架构分析及改造-产品SaaS化带来的架构思考 赵军伟 IBM架构师
背景
PANDA团队一直负责HORIZON产品的开发工作，并与UX（用户体验设计）团队，QA（质量保证）团队，SU（服务）团队一同提供产品生命周期内的发布和支持工作。在过去几年中，该产品一直服务于企业用户，按照安装数目授权的方式销售给用户。从去年开始，按照公司战略方向的调整，所有产品都迁移到云上，以SaaS的产品方式发布，服务大量并不具备IT基础架构的小微企业，同时保持现有已安装企业用户本地部署的支持，并为他们提供逐渐迁移到SaaS上的解决方案。
HORIZON产品已经有十年以上的历史，其最初设计并没有考虑对云，尤其是多租户的方案支撑，而仅仅是一个便于安装部署的单体架构，功能架构如图一所示。部署架构如图二所示。
在***步迁移到云时，为了快速可用，我们做了一个仅仅是自动化部署以及和门户的集成工作，并未在基础架构上做任何调整。相当于把原有在企业用户中安装的版本在云上为每个用户做了一个自动部署，实际上每个用户还是独立的享有一个VM，而不是多租户的模式。虽然这样做可以非常快地完成公司战略转移的要求，但同时也带来了比较多的问题：
1.资源浪费。在企业用户中，服务端需要一个8核以上CPU，16G以上内存的服务器，以接入多达5000个以上的探针采集器。但在云上很多小微用户也不得不使用一个类似配置的虚拟机，即使用户只接1个探针。这种方案极大浪费了服务端资源，无法做到处理能力的有效发挥，从成本上也投入很高；
2.无法横向扩展。所有的模块都安装在同一虚拟机内，模块间的通信已经配置为本地连接，不能扩展到多台服务器部署，且每个模块无法启动多实例以提供更多的处理能力，在将来扩展到多租户支持上存在架构上的设计缺陷；
3.没有容错方案。如果某个模块出现僵死或者崩溃的情况，没有统一的管理框架去自动监测并启动失败模块；对于模块失败后手工恢复缺乏统一的状态恢复方案；即使增加前面两点讲到的缺失功能，对于虚拟机整体崩溃这样的事情也超出了该架构能够处理的范围。
图一 既有技术架构
图二 既有部署架构
现有架构分析
现有架构均基于企业安装用户快速部署的需求，并没有针对云，尤其是多租户的部署模型有考量。因此，首先要针对基于云的SaaS解决方案提出架构改进的需求：
1.多租户支持。多租户支持主要解决多个用户共享服务器上计算，存储，网络等资源，以细粒度方式调度资源，达到资源的有效利用；
2.水平扩展支持。每个模块必须做到多实例支持，以组成数据处理集群，通过多个实例协作突破单个实例处理上限，并在多租户的场景下做到那个模块处理能力不足便扩展哪个模块，达到资源高效利用；
3.容灾设计。每个模块本身的功能集合均可认为是一种服务提供，该服务对于服务的消费者具有透明性，或者说服务消费者并不需要关心服务提供者有多少个实例，也不关心具体由那个服务实例提供服务。即使一个服务实例崩溃，系统能自动屏蔽到该实例的请求，从而做到服务的不中断执行，且系统能够恢复崩溃模块到可用状态，从而保证服务质量不下降；
4.自动化运维。模块实例随着用户数量增加而不断增加，当达到一定规模之后，传统系统运维的弊端就逐渐显现，甚至变为不可能。自动化运维要求系统对于常见的水平扩展/收缩操作，崩溃模块实例的恢复，服务提供者和消费者的连接配置，新建实例的配置更新等均做到自动化，并提供报告以逐步优化；
5.数据安全与数据完整性。多租户需求带来了安全性的要求。每个用户都希望自己的数据在SaaS服务上是安全的，不被未授权用户访问和篡改；同时，即使是同一租户的不同业务部门，也有数据权限的设置，以保证企业信息的正确使用。数据完整性的保证包括了数据的不被篡改，也同时要求数据的一致性，可恢复性，可追踪性；
6.可维护性。该特性并非为终端用户所要求，而是由于SaaS运维操作集中于运维团队，面对庞大的用户群体，高度可维护性能够极大增加系统的可用性和出现问题时快度修复的速度;
7.DevOps。该特性同样为运维团队需求。以SaaS方式发布产品，要求改变传统半年一个版本发布周期的传统，尽可能快速推出新的功能，提高用户满意度。另外DevOps也要求建立一个自动化的发布流水线，在流水线的每个环节保证发布的质量，避免出现问题版本到达终端用户的情况发生。
上述需求为迁移到云的基础要求，另外还由此引入一些非直接的衍生需求，我们将上述所有需求整理为如下几个方面：
1.功能模型。功能模型的变化主要为部署模型从传统的单体式模型变为分布式模型引入的新特性导致的。或者可以表述为部署模型倒逼功能模型的一种方式。在传统的功能实现中，主要以快速满足用户需求为主，并没有考虑分布式部署带来的额外的非功能需求，例如可维护性对大规模分布式部署的集中日志查看需求，多实例对于集群管理的任务分配，数据分区，配置更新，缓存同步等引入的新需求等等；
2.部署模型。部署模型以分布式部署为主要考量，并做到集群实例分散部署以减少集中部署中对底层IT支撑系统单点失败带来的压力；部署方式还应支持分布式部署的运行时配置，自动将互相依赖模块的连接关系配置完成；部署方式能够做到服务隔离，在实例失败时屏蔽其功能并在自动恢复后继续为服务消费之服务；部署分布式系统时能够支持弹性伸缩；
3.流程更新。运维团队和开发团队更紧密的结合，梳理发布流程，改变以前瀑布式开发，阶段性发布的模式，将SaaS服务做成真正自动化的云发布流水线。更紧凑的发布节奏要求更严格的质量控制，这些都要求更多的构建，功能测试，压力测试，集成测试，全球化测试等步骤被自动化，且能够做到流水线阶段提升。
根据上面的分析，我们可以有针对性的对现有技术架构做改造升级，以适应新的应用环境。
架构改造方案
功能模型
从云的特性讲，分布式部署、弹性伸缩和容错设计要求我们做到服务/组件的隔离和发现，并在每个服务/组件内做到集群管理功能。从图一的功能模型可以看到，目前组件已经具有了比较规范的边界划分，但在隔离度和动态配置上尚有欠缺。故做功能模型改造如图三所示。
图三 改造后功能模型
此图中，各个组件分别构建为一个微服务，每个微服务为自承性的组件，通过与其他服务交互共同完成整个产品的功能集合。各个微服务之间通过两种方式相互连接：
1.数据总线。数据总线提供队列和发布/订阅支持，以解耦服务的提供者和消费者之间的直接连接。由于有服务总线的隔离，服务提供者和消费者并不直接互联，且互相不知道对方的存在，故而对于任何一方只需要和数据总线通信就足够了。这也提供了可插拔的一种服务配置方式，对于灵活扩展数据处理服务提供了极大的支持。
2.RESTFul服务。大部分的服务不仅供产品组件使用，同时也提供外部产品集成的能力。此时组件应该暴露RESTFul API给服务消费者。通过这种方式，各个组件仅需要使用一种最通用的通信协议即可和很多种服务通信，避免了多种协议适配带来的额外工作量。
组件的实现要尽可能做到无状态化，这样新的实例将不必与其他实例通信以恢复或者同步状态，而是仅仅提供计算能力，或者仅仅通过与某种持久化层服务即可获取本服务的状态，并快速对外提供服务。
部署模型
部署模型对于功能模型是透明的，即功能模型的实现可以在不同的部署环境里通过部署适配做到灵活部署。
鉴于部署在云中的运行时配置在微服务架构下较为复杂，需要针对组件抽象出服务的发现与自动配置，这些功能不能实现在组件代码里，而是实现在云环境适配代码里。注意，此处云并非单指公有云，也包括私有云和混合云，这样对于传统企业用户，尤其是对数据安全性高的企业仍然能够提供支持。功能代码和适配代码的分离可以带来稳定的功能组件和可裁剪的环境适配上的便利性。
对于上述配置的分离，部署模型上采用每个微服务均以Docker镜像的模式发布（功能代码封装），并在不同云环境适配中对于Docker镜像做运行时配置，一般我们依赖于云提供商的编排服务（环境适配代码封装）。
此处我们采用目前比较热门的Docker+Kubernetes，修改部署模型的设计如图四所示。
图四 改造后的部署模型
Docker镜像保证里每个服务在运行时的环境一致性，包括Linux的发行版，运行依赖库等所有本地依赖，而Kubernetes则通过Service这个概念解耦了两个服务之间的直接连接，天然地为服务解耦，服务自动发现和自动配置，甚至是弹性伸缩提供了基础架构级别的支持。
图四中给出了一个服务A的部署例子，该服务A除了与总线通信外，也同时通过数据库持久化层暴露的RESTFul服务完成状态的持久化和还原操作。同时，每个实例的分布式部署会考虑跨机柜，甚至是数据中心（如果需要这么高的可用性的话）的配置策略。以获取足够高的可用性。
目前Kubernetes提供了各种IAAS的适配，该模型同时利用了这种开源框架的适配能力，在各种云，如AWS，Azure，甚至是企业内部的VMware集群中均可以做到部署和编排。这大大减少了我们自己适配各种IAAS的工作量。
流程更新
构建自动化的发布流程即使是在传统的瀑布开发模式时代，产品中已经有大量采用，不过当时主要是解决多个模块自动化测试，以减少集成风险为目的。而在采用云的服务发布模式以后，DevOps的采用势必成为一种流程上的强制要求，并上升自动化测试为自动化发布，缩短发布周期的同时保证发布的质量。
根据现有团队的服务支持模式，需要调整部分服务支撑人员到新的运维团队，并与研发团队一同工作，保证产品质量的同时实现快速的迭代发布。研发团队不仅负责产品的功能开发，同时自动化测试，云环境适配的开发工作也同时需要在研发团队完成；运维团队针对产品上线后的问题，实时反馈给研发团队并据此更新优化。在此我们主要关心自动化DevOps的流水线设计，其它部分不在本文讨论范围之内。
DevOps的流程设计如图五所示。
图五 改造后的DevOps流程
1.开发人员完成代码在IDE环境中单元测试之后，需要提交代码到源码库，代码包括产品代码，测试代码，云环境适配代码。DevOps通过工作流调度程序自动触发产品的构建，Docker镜像封装，自动化部署到沙盒再次运行所有自动化测试脚本；
2.当上述测试通过后，Docker镜像和云适配配置自动提升到集成测试环境（图中iBVT），与其他开发小组提升的组件集成，做集成测试；
3.集成测试通过后提升到复杂场景测试环境（图中SVT）。复杂场景测试模拟真实用户的操作，把各个产品功能串在一起完成典型用户场景和异常用户场景的测试；
4.SVT通过后提升到预演环境（图中Staging），该测试除了通过完整回归验证产品的功能，性能外，还要经过至少一个星期的稳定性测试；
5.最终通过的产品版本自动提升到产品环境（图中Production），为终端用户提供服务。
上述任何一个环节出现问题，自动提升的条件便会收到破坏，系统会通知开发团队修复错误，重复上述流程。
总结
一个完成的架构迁移，不仅仅涉及到功能模型，部署模型等传统技术架构所应用的范围，实际上团队技能的调整，角色的边界定义，甚至是组织架构的优化都对一个产品架构的迁移有着非常重要的影响。作为一个技术主管，需要从各个视角，多维度地观察和解决在改造迁移过程中发现的短板，不断迭代优化，从而最终保证目标的达成。
导师点评：跟谁学联合创始人李钢江
评分：92
评语： 文章说明了一种典型的SAAS服务改造的场景，***补充一些量化的数据说明改造的成果，在创新性方面做的稍有不足，不过整体做的不错，体现了作者实施复杂项目研发管理的能力。
CTO训练营是51CTO高招主办，面向中高端技术管理者的学习分享及社交平台，汇集业界资深技术高管、投资人资源，以“打造技术经理的MBA”为核心，全心全力帮助中国***潜力的技术管理者，成长为未来技术领域的***及榜样。第三季CTO训练营将在原有优质内容体系的基础上，延伸四大选修活动，满足不同技术管理者的个性化需求。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
