东软SaCa Aclome云管理平台架构演进之路

Presentation on theme: "东软SaCa Aclome云管理平台架构演进之路"— Presentation transcript:

1 东软SaCa Aclome云管理平台架构演进之路
赵 玮 产品经理 东软集团

2 摘要 案例简述 案例背景 成功要素 案例实践 发展规划 ROI分析 案例启示

3 案例简述 案例说明 案例目标 SaCa Aclome是面向企业的云管理平台软件。随着客户需求的不断变化，以及为了满足产品未来的发展，产品自身的架构需要从最初的封闭式架构升级为组件化可扩展的平台式架构，从而降低开发门槛，吸引更多的定制化开发人员参与到Aclome的生态系统中，以快速满足客户的定制化需求。 通过对原有业务梳理和底层架构的升级改造，降低软件扩展开发和实施部署的成本，从而实现灵活适应功能性与非功能性两方面的需求差异与变化，并解决生产模式与效率问题，做到规模化的跨团队甚至跨组织合作生产，建立以产品和核心的生态系统。

4 案例背景 前台 OC BC CSS OC服务 BC服务 通用模块
Aclome已有架构是比较封闭的架构，前后台独立，之间通过Rest接口调用，前台基于SSH开发，后台为 独立运行Java程序，代码之间的耦合度较高，并且不利于集群部署。 前台 规模 难规模化 维护 后台会越来越臃肿，各模块之间耦合越来越强，难以维护 部署 各个模块间耦合强，无法拆分不同的版本。 沟通 前后台REST接口。定制化开发人员学习成本较高 OC BC CSS OC服务 （管控） BC服务 （交付、计费） 通用模块 （监控、统计、告警）

5 案例背景 现状分析小结 在产品发展迅速，特性更新、扩充较快的形式下，结合产业变革的外部环境，当 前的技术架构已不能满足产品发展的需求，主要体现在以下几个方面： 从产品交付角度：无法做到“按需交付”和“持续性交付”产品服务。 从产品生产角度：难于做到“规模化的”跨团队甚至跨组织合作生产。 从产品质量角度：难于应对潜在的“应用性能”问题。 从产品周期角度：难于做到“可持续性的”产品改良演化。 为应对以上问题，决定将产品的架构升级为“面向服务的组件化”架构。

6 成功要素—面向服务的组件化架构 面向服务的组件化架构 构建应用的框架和模型应能适应环境的变化，完成自动管理和监控； 组件库的应用；
来自： Mark Little JBoss 技术总监 Eberhard Wolff Spring Source首席技术专家 Parallel Universe Co. Blog 新兴技术咨询公司 …… 关于主题“现代Java Web应用的开发与部署”，当前有来自业界的以下观点值得注意： 构建应用的框架和模型应能适应环境的变化，完成自动管理和监控； 组件库的应用； 所有的应用和服务可以根据需要动态添加； 管理跟踪对象和服务的依赖，以便于迁移或变更时，相关的服务和对象能够保持兼容； 服务化、分布式是应用的发展方向； …… 面向服务的组件化架构 应用域 (1) Instance_1 (4) Instance_2 APP_Part1 <集群> APP_Part1 组件库 应用终端服务 (2) <依赖> APP_Part2 (3) 图例： APP_Part3 运行时管理与监控 应用进程 ：应用组件 ：发布与部署

7 成功要素—全新的产品架构模式 持续性交付应用服务 动态负载均衡 保证应用服务高可用 支持异构系统集成 v2.0 敏捷云应用管理平台 v2.0
（1）组织安全 （2）资源交付 （3）资源监控 v2.0 敏捷云应用管理平台 门户 门户 门户 （2） <应用菜单> 虚拟机申请 资源管理 …… （1） <应用菜单> 组织划分 人员管理 …… （3） <应用菜单> 虚拟资源监控 …… 相关异构系统 资源交付 组织与安全 资源监控 v2.0 资源交付

8 实践 1架构基础设施——RPC框架 须有一套分布式服务框架，提供高性能和透明化的RPC远程服务调用方案，以及服务化治理方案。
面向Java应用开发 屏蔽调用原理机制 高性能 面向接口 集成基础开发框架，如Spring Framework RPC框架容器 门户 安全管理 组织机构 交付 监控 告警 <注：仅为示意图，无实际意义，以最终设计为准> 使用<接口> 完成编译 组件A 组件B JVM 组件A 组件B JVM_1 JVM_2 spring_beans.xml 组件A 组件B 集成<Spring> 注入接口实例 interfaces.jar 屏蔽环境差异，自动适应 保证高性能通信 面向接口 集成基础开发框架

9 实践 2架构基础设施——组件资产与资产库 组件资产 资产库与资产用户 资产库的软件分析能力 组件API规范
从应用服务角度来看，各组件应是垂直、独立的Web应用（开发工程），能提供一套相对聚合的功能特性集。 在符合一定的简单组件规范的前提下，多个相关（功能组合或程序依赖）组件的发布和部署可具有动态性特征： 组件合并发布，集中部署； 组件隔离发布，分布式部署。 资产库与资产用户 对于各组件资产，不同涉众角色，出于不同目的可得到不同形式的组件形态。 资产库应与源码版本控制系统集成，进行组件开发版本管理工作，进而开发者可获得组件源码版本。 对于各开发版本基线，可直接获取具有动态性特征的部署版本资产。 组件资产库 <源码组件> <部署组件> 开发维护人员 实施运维人员 资产库的软件分析能力 资产库有能力静态分析组件依赖关系网络，包括： 依赖分析 被依赖分析 依赖关系分析能够给出源码级别的依赖详情。 组件API规范 各组件对外暴露的API接口，由资产库生成JavaDoc进行说明。 组件A 组件C 组件D 组件B 组件 √ 组件A 组件C 组件D ClassA -> Interface1 -> Interface2 ClassB -> Interface3 组件B

10 实践 3架构基础设施——开发环境 关键在于统一的开发标准及规范以及开发工具 组件化开发 导航视图 集成资产库 自动化 构建与发布

11 实践 4POC选型 选取现产品中的典型功能特性，经迁移改造，落地于一种面向服务的组件化架构方式，在这个过程中采用了两个不同的
组件列表 UVS：Unified virtualization service，统一 虚拟化管理操作服务组件。 门户：应用功能视图的统一访问入口。 组织机构：基础业务组件。提供组织人员管 理控制台功能及相关服务接口。 安全管理：基础业务组件。提供资源权限管 理控制台功能及相关服务接口。 交付：应用组件。（提供资源申请审批功能 及相关服务接口） 操控：应用组件。（提供资源操作、控制功 能及相关服务接口） 监控：基础技术服务组件。 （提供资源监控 数据采集功能及相关服务接口） 告警：基础技术服务组件。 （提供资源策略 配置、生成告警功能及相关接口） Ethernet（ ） 门户 组织机构 安全管理 操控 交付 UVS 监控 告警 UVS Step1:部署“基础管理控制台” 从资产库获取组件集{“门户”，“组织机构”，“安全管理”}部署程序，部署于 。 至此，用户已能访问到“基础管理控制台”应用。 Step2:添加“资源申请与操控”功能 从资产库获取组件集{“操控”，“交付” ，“UVS”}部署程序，部署于 。 至此，用户已能访问到“资源申请”、“资源操控”功能集。 Step3:添加“资源监控与告警”功能 由于添加了“资源监控”功能，对UVS服务的压力增大，UVS的可用性也成为了关键点。故决定，再增加一个UVS实例。 从资产库获取组件集{“监控”，“告警”，“UVS”}部署程序，部署于 。 至此，用户已能访问到“资源监控”功能集。 并且，分别处于154和162节点的两个UVS实例，将共同承担服务压力。

12 实践 5团队激励（待补全） 架构的调整对已有团队人员的影响 1、强调架构升级的意义及重要性，让大家统一认识，发挥主观能动性
2、对于老结构的核心人员，帮助树立新的目标，找准新的定位 3、要做好人员流失的准备，并及时补充资源。

13 发展规划 概述 当前各产业均向“生态化”理念靠拢，其实质在于形成一种具有自适应性的，跨区域、组织、职能的规模化协同生产 模式。一个健壮的产业生态所迸发的生产力和产业价值远胜于传统的集中性、计划性的生产组织。 观点 以落地的服务化产品架构为基础，可组织构建一种生态化的生产模式，以突破产品发展过程中的生产效率瓶颈。 价值依赖： 生产职责： 产品Roadmap规划 基础技术、公共服务、业务支撑类组件开发维护 基本业务应用类组件开发维护 研发平台工具开发与维护 …… 产品负责团队 公司业务单元 合作厂商 产品市场经营与商 业价值化 研发平台设施与技 术支持 定制化、个性化业务应用组件开发 业务支撑类组件扩展 …… 上下游合作业务集成 ……

14 直接效果 投入 间接效果 案例ROI分析 架构梳理 4人月 支撑项目同比提高 120% 满意度提高 选型POC 8人月 易用性增强
架构梳理 4人月 选型POC 8人月 工具提供 6人月 架构改造 41人月 间接效果 满意度提高 易用性增强 生态系统逐步建立 直接效果 支撑项目同比提高 120% 销售合同额提升110% 性能提升50%

15 案例启示 为何升级 统一目标 原型验证 新老交替 试着折衷 不是为了升级而升级，而是为了更好的支撑业务的发展，架构升级成本较高，要慎重
在整个工作开始前，一定要让团队中虽有的人达成一致共识，动员大家向同一个目标努力，充分调动积极性 统一目标 面对团队中不同的改造意见，一定要组织原型验证，通过实际结果来选择最佳的方案 原型验证 新架构的升级会损害老员工的利益，要对他们有所照顾，不过也要做好人员离职的准备，同时也要在改造的过程中让新人快速成长 新老交替 试着折衷 架构改造是要考虑对老版本的影响，在新版本的改造和老版本的交付及维护之间要找到折衷的方案