|
导读 ： SaCa Aclome是面向云应用的通用云计算管理环境，旨在为企业云数据中心提供支持多种虚拟化及云平台的快捷部署、集中监管、弹性伸缩、按需供应等云计算关键功能，可有效降低解决方案在开发与部署环节的硬件成本及后续的升级与维护成本，提升解决方案的适应能力。 本案例将详细介绍东软SaCa Aclome云管理平台从封闭式架构升级为组件化可扩展的平台式架构的演进过程，以及如何解决生产模式与效率问题，做到规模化的跨组织合作生产，建立以产品为核心的生态系统。 （全文共3784字 预计阅读时长：4分钟） 一、案例背景 SaCa Aclome是面向云应用的通用云计算管理环境，旨在为企业云数据中心提供支持多种虚拟化及云平台的快捷部署、集中监管、弹性伸缩、按需供应等云计算关键功能，可有效降低解决方案在开发与部署环节的硬件成本及后续的升级与维护成本，提升解决方案的适应能力。 随着客户需求的不断变化，以及为了满足产品未来的发展，产品自身的架构需要从最初的封闭式架构升级为组件化可扩展的平台式架构，从而降低开发门槛，吸引更多的定制化开发人员参与到Aclome的生态系统中，以快速满足客户的定制化需求。 通过对原有业务梳理和底层架构的升级改造，降低软件扩展开发和实施部署的成本，从而实现灵活适应功能性与非功能性两方面的需求差异与变化，并解决生产模式与效率问题，做到规模化的跨团队甚至跨组织合作生产，建立以产品为核心的生态系统。 二、案例复现 SaCa Aclome已有架构是比较封闭的架构，如图1所示，前后台独立，之间通过Rest接口调用，前台为基于SSH开发的Web应用，用于展现，后台为独立运行Java程序，用于资源的管理，但是各个模块间耦合度较高，无法高效拆分不同的版本，并且随着功能的增加，后台变得越来越臃肿，各模块之间耦合越来越强，不利于扩展，难以维护。同时前后台REST接口，定制化开发人员学习成本较高，如图2所示。 图1 SaCa Aclome技术架构 图2 相继而来的问题 ● 2.1 SaCa Aclome技术架构的缺点 在产品发展迅速，特性更新、市场扩展较快的形式下，当前的技术架构已不能满足业务发展的需求，主要体现在以下4个方面：
● 2.2 面向服务的组件化架构的优点 为应对以上问题，决定将产品的架构升级为“面向服务的组件化”架构，新的架构具备如下优势：
通过组件化技术将产品按照业务功能分割成多个组件，根据客户的实际需求，提供必要的组件，通过组件装配技术快速交付给用户使用，并且在后期功能升级时，也只需将新增的组件部署在客户的生产环境中即可，做到平滑升级和可持续性交付。
通过组件化改造，一方面可以通过新增组件的方式完成客户的扩展功能，另一方面在某些功能组件不满足实际客户需求的情况下，可以进行组件级的定制化开发，通过更换特定组件实现客户需求。
构建应用的框架和模型应能适应环境的变化，完成自动管理和监控，并且通过容器化和热部署技术保证自身系统的高可用。 改造后预期的产品弹性架构如图3所示。 图3 改造后预期的产品弹性架构 三、技术要点 ● 3.1 原型验证 在确定了架构升级的原则和目标后，研发人员对于如何实现有着不同的理解，主要存在两种观点：
为了保证升级能取得预期的效果，确定同时对两种方案进行原型验证，采用典型的业务场景，分别用两种技术方案，进行POC验证，以决定哪种方案更适合。 POC过程要重点体现：组件资产管理、按需交付、持续性动态交付、灵活适应需求与环境变化这些特点。 具体的POC业务场景如下。 Step1：部署“基础管理控制台” 从资产库获取组件集{“门户”，“组织机构”，“安全管理”}部署程序，部署于10.4.55.156。至此，用户已能访问到“基础管理控制台”应用。 Step2：添加“资源申请与操控”功能 从资产库获取组件集{“操控”，“交付”，“UVS”}部署程序，部署于10.4.55.154。 至此，用户已能访问到“资源申请”、“资源操控”功能集。 Step3：添加“资源监控与告警”功能 由于添加了“资源监控”功能，对UVS服务的压力增大，UVS的可用性也成为了关键点。故决定，再增加一个UVS实例。 从资产库获取组件集{“监控”，“告警”，“UVS”}部署程序，部署于10.4.55.154。 至此，用户已能访问到“资源监控”功能集。并且，分别处于154和162节点的两个UVS实例，将共同承担服务压力。如图4所示。 经过一个月的验证和测试，以及多轮演示和开会评审，大家一致认为基于分布式服务调用框架的组件化技术能更好的满足未来的发展需要，最终统一了思想认识，确定了升级工作所采用的技术路线。 图4 添加“资源监控和告警”功能 ●3.2 基于Dubbo的服务调用框架 基于Dubbo的分布式服务框架，提供高性能和透明化的RPC远程服务调用方案，以及服务化治理方案。 对于服务框架要遵循以下原则，才能满足实际的业务需要：
为了降低入门门槛和降低开发工作量，需要对开发人员屏蔽组件间的调用机制，摆脱传统的通过Rest方式的接口调用。
基于分布式的服务接口调用的性能一定要高于传统的Rest调用方式。
组件间的调用只能通过每个组件对外暴露的接口调用，保证组件之间的解耦。
需要将业务基础功能组件进行封装，做为基础开发框架。 基于这些要遵守的原则，我们基于开源的Dubbo架构，对已有的代码进行整体的重构，先划分业务组件，然后再结合实际情况进行功能组件拆分，确定了要将整个系统划分为43个功能组件，其中包括微内核、缓存、菜单、日志、组织机构、权限、采集、分析等基础组件，形成完整的基础开发框架，如图5所示。 图5 RPC框架容器 ● 3.3 组件化开发工具 为了方便开发人员基于新框架进行开发以及整个开发环境的快速构建及调试，我们又基于Eclipse进行了扩展和封装，最终提供基于统一开发标注及规范的专用开发工具，如图6所示。 快速开发工具具备如下功能：
图6 快速开发工具 ● 3.4 组件资产与资产库 为了更好的管理业务组件，做到业务组件的最大复用，需要提供组件资产库，应具备对组件的上传下载功能、组件库版本管理功能、组件依赖关系分析和校验功能、组件使用情况跟踪和查询功能、组件复用占比统计分析功能等。 组件资产 从应用服务角度来看，各组件应是垂直、独立的Web应用（开发工程），能提供一套相对聚合的功能特性集。在符合一定的简单组件规范的前提下，多个相关（功能组合或程序依赖）组件的发布和部署可具有动态性特征：
所有基于开发工具开发的业务组件均要满足这些原则和要求，才能做为组件资产发布到资产库中。 资产库 资产库出了要提供资产上传、下载、检索及版本管理的基本功能之外，更要提供如下能力：
对资产库做用户授权，对于各组件资产，不同涉众角色，出于不同目的可得到不同形式的组件形态。
资产库有能力静态分析组件依赖关系网络，包括：依赖分析、被依赖分析。依赖关系分析能够给出源码级别的依赖详情。
根据业务组件内部标识的JavaDoc，结合各组件对外暴露的API接口，由资产库生成接口说明。 ●3.5 团队激励 在架构升级的整个过程都要对团队进行有效的激励和引导，对不同阶段的员工，要采取不同的鼓励措施。 在工作正式启动前，要尽量和团队成员达成一致，同一目标，让大家认识到整个工作的重要性和紧迫性，尽可能调动大家的积极性。 对老架构的升级，势必会影响到熟悉旧架构的开发人员，他们往往都是工作多年经验丰富的研发人员，难免会对升级工作有抵触情绪，需要针对每个人的具体情况，做行之有效的沟通和引导，明确他们在新架构之后的定位，经过沟通后虽然大部分老员工都认可升级工作的重要性，但是工作启动后还是有近一半的老员工选择离职，对整个升级的工作也造成了一定的影响。 在工作启动时，已经明确了以几个两年左右工作经验的新员工为核心，充分调动他们的积极性，主导整个工作的进行，同时积极开展社会招聘，补充新人到整个团队中，及时填补了人员的缺口，保障了整个升级工作的顺利进行。 四、成果展示 经过为期半年的组件化架构升级，升级后产生的直接效果为在团队人员数量没有变化的情况下，同比支撑的项目数提高120%，合同额增加一倍多，并且系统性能提升50%，提高了用户满意度。 五、案例启示 面向企业的云管理平台是个需要定制化的产品，如何多、快、好、省的完成定制工作是产品成败的关键，通过对Aclome云管理平台组件化架构升级工作，给我们的启示为：
不是为了升级而升级，而是为了更好的支撑业务的发展，架构升级成本较高，要慎重。
在整个工作开始前，一定要让团队中所有的人达成一致共识，动员大家向同一个目标努力，充分调动积极性。
面对团队中不同的改造意见，一定要组织原型验证，通过实际结果来选择最佳的方案。
新架构的升级会损害老员工的利益，要对他们有所照顾，不过也要做好人员离职的准备，同时也要在改造的过程中让新人快速成长。
架构改造是要考虑对老版本的影响，在新版本的改造和老版本的交付及维护之间要找到折衷的方案。 ★★征稿★★ 寻找100个年度最具价值的实践案例 我们只要案例干货，拒绝广告 成为特约作者，你将： ◆ 连接100名年度经验与增长值TOP100的研发精英 ◆ 提前入围「壹佰案例」年度最优案例榜单 ◆ 案例整理成册，出版发行图书 ◆ 成为msup客座教练 ◆ 以观察员身份受邀出席壹佰案例 ◆ 所在公司享有msup活动优惠 有意者guanzhu「壹佰案例」 |
|
|
