大型企业云平台架构和 关键技术实践 华为公司 华为软件云平台架构师 苗彩霞 自我介绍 苗彩霞 华为软件云平台架构师 • 2000年加入华为，历经了华为软件的 发展和技术演进与变革 Ø融合智能网业务平台 Ø分布式SOA中间件平台 Ø微服务化云平台DigitalCube 大型企业软件架构的挑战1 微服务架构的实施实践2 微服务架构新的关注点3 目录 复杂企业应用的特征和云化巨大挑战 华为电信软件的挑战： Ø 一套软件交付全球上千局点，新需求/新特性/特性变更频繁 Ø业务复杂，周边几十上百个系统，千余人并行开发上百个模块 Ø大/中/小局点（用户从数亿到数十万不等）要求部署灵活，部署维护成本低 Ø契约化产品交付，5个9的可用性 B2B企业应用B2C消费者应用 庞大复杂的企业软件如何做到高效敏捷、弹性、自动化？ User UserUser User User User User UserUser User User User Application 平台、用户、功能 System&DataApplication Application System&Data User User User User flow flow flow flow 平台、应用、数据 解决问题的关键思路 集约化云化建设， 可扩展性和伸缩性 大系统小做，快速创新 敏捷运营，Easy运维 海量灵活变更、快速 上线 自动部署、弹性伸缩 分而治之、自动运维 服务架构演进之路 表现层 逻辑层 数据层 服务总线ESB 系统1 系统2 系统3 系统n 事件驱动 功能 分割 数据 分割 无中心集群 MVC架构 SOA服务架构 可伸缩架构 微服务架构 1、MVC：解决前后端、界面、控制逻辑和业务逻辑分层问题 2、SOA：服务化架构，企业级资产重用和异构系统间的集成对接 3、RPC/事件驱动可伸缩架构：远程过程调用，无中心集群，本质是系统解耦和分布 式通信 4、微服务化架构：功能细粒度解耦，服务自治，敏捷交付、云计算、容器化发展的 产物 华为软件微服务架构视图 资源调度 微服务框架 运维系统生命周期管理 运维分析 部 署 升 级 灰 度 伸 缩 持续交付流水线 开 发 服务注册中心 (Zookeeper) 监控系统 运维 展现 服务通信 (Netty+ProtocolBuffer) 服务治理 服务运行容器 (OpenAS,CSC) 开放 接口 分布式数 据访问 分布式 缓存 服务负载均衡&路由 信息收集 批价 鉴权 余额 管理 业务组件服务 语音业 务计费 转帐 信控 … 出账 营业 收费 用户 开户 产品 管理 余额 管理 业务流程服务 产品 订购 客户 管理 … 资源 管理 收入 管理 缴费事件 计费 出账流程（示例） 调账 >100 业务流程服务 >40 核心组件服务 漏斗形的服务模型，支撑快 速构建新功能和新流程 “经验” u行业领域经验 u工具 u迭代实践 “标准” uTMF u业务/技术规范 u… 1、服务化拆分切莫忘了初衷 2、识别业务领域模型，以业务对象为核心进行微服务设计 3、不要一味追求扁平化的微服务，做好微服务分层和聚合 4、服务的数据完整性是关键 #1 微服务的设计 微服务设计的实践总结 微服务拆分原则：围绕业务功能进行垂直和水平拆分。大小 粒度是难点，也是团队争论的焦点。 Ø 以代码量作为衡量标准， 例如500行以内 Ø 拆分的粒度越小越好 Ø 只关注功能不关注数据 不好的实践： 建议的原则： Ø 以领域模型为中心、功能完 整性、职责单一性 Ø 粒度适中，团队可接受 Ø 迭代演进，非一蹴而就 Ø API和兼容性优先考虑 Ø 交互性能、部署综合考虑 #2 基于微服务的开发测试和构建 即需即用的 PaaS环境 动态环境分配 自动部署 自动集成验证 自动用例执行 Sandbox/镜像 测试 服务并行开发 微服务框架&规 范 模板化 测试&仿真 接口MOCK契约测 试 仿真测试 1、众多的微服务，接口交互和业务协同复杂问题通常引发灾难 2、微服务模板化、框架化、工程化是保证开发效率和质量的基础 3、做到 “开发即测试+每日端到端集成构建 ”是关键 自动打包发布 依赖和合规检查 自动打包 “自主性” “一致性”… 框架+模板 环境+测试… 微服务的开发构建的实践总结 Ø 服务提供者专注于内部实现， 而不是优先提供契约化的接口 Ø 担心接口变更，迟迟不提供接 口契约，消费者无法并行开发 Ø 只重视快速开发，堆到最后联 调测试发现问题 微服务开发构建原则：接口先行，语言中立，并行开发， 提升产能；自动测试和版本级持续构建，持续集成联调。 Ø 接口优先 Ø 契约驱动测试，实现服务提供 者和消费者解耦 ØIDL，代码骨架自动生成 Ø每日构建、持续集成联调，快速发 现和解决问题 Ø 允许契约的变更，但项目组需 就接口的兼容性做约束 不好的实践： 建议的原则： #3 微服务的云化自动部署 1、服务独立打包，物理交付件独立 2、基础设施自动化，异构I层（PM/VM/Docker） 3、自动部署（部署引擎、并行分发和执行、Docker） 4、持续交付流水线（CD pipeline、sandbox） 资源 动态 调度 自动部署引擎 并行 分发 执行 自动 配置 软件制品仓库 promotion policy account Foun.jar customer policyNotification.jar Inventory order.jar plan.jar payment.jar 启 动 升 级 停 止 回 滚 下 线 测试环境 Sandbox 灰度环境 生产环境 镜像环境 DEV环境 CD环境 微服务的大规模节点部署 量变到质变，企业级大规模部署需要考虑的问题： 1、如何支持多国多地部署？ ->分层分布式部署：资源分域、服务分组、AA容灾 2、千级万级节点同时部署，带宽开销与节点数成倍增加？ ->分布式软件仓库、P2P高速软件分发 3、部署中遇到各种部分异常，如何处理？ ->断点续传、断点续做、失败重做 软件仓库 调度控制 P2P分发服务 节点分组1 节点分组2 P2P分发架构分层分布式部署方式 Resource Central 无锡中心 苏州中心 南京中心 二叉树分发 模式1 模式2 链式分发 P2P分发模型 微服务部署的实践总结 Ø 微服务混在一起部署， 无法独立伸缩和启停 Ø 无法分批部署/升级，需 要串行操作 Ø 无法优雅升级，升级中 断业务 微服务部署原则：独立交付件、独立生命周期管理、 基础设施自动化、部署自动化并行化 Ø 微服务可独立发布、部署、升级、 扩容、灰度 Ø 服务基于性能和成本可考虑合设， 但核心服务和非核心服务隔离部署 Ø 基于docker部署，线上线下环境 一致 Ø 部分失败不影响部署任务，支持可 人工干预失败处理 不好的实践： 建议的原则： #4 微服务的治理和运维 1、微服务运维能力内置在服务框架中，框架化、自动化、实时化 2、运维数据：CMDB系统信息+实时动态运维数据+分析数据 3、服务调用链非常关键，并建立性能瓶颈分析、用户体验分析、 故障分析模型和规则 4、一定考虑运维数据的对外开放性 智能分析系统 CMDB 运维数据 ü资源信息 ü中间件信息 ü服务运行信息 ü服务调用链 分布式服务 雷达系统 在线治理和故 障处理 展示&OpenAPI ü实时流处理 ü大数据分析 üElastic Search ü容量预测 ü规则模型 “框架化” “智能化”… 微服务的在线治理架构 服务治理Portal 服务治理元数据 服务治理接口 服务治理展 示层 服务治理服务集群服务注册中心集群 Governance服务层 微服务治理策略： 1. 流量控制：动态、静态流控 2. 服务降级 3. 超时控制 4. 优先级调度 5. 服务智能路由 6. 服务实例接管/流量迁移 7. 服务迁入迁出 8. 调用链跟踪和分析 9. SLA策略控制 10. 服务伸缩... 服务治理SDK KPI 调用 链 state event ü服务自治，服务精细化管控 ü在线治理，动态实时生效 微服务运行需要考虑的问题：分布式事务 事务一致性：大部分采用最终一致性、极少部分需要强一致性 本地事务： 分布式事务： 策略： 1. 最终一致性， 消息中间件 2. 强一致性，TCC（ Try-Confirm-Cancel） 微服务运行需要考虑的问题：性能和时延 微服务技术上的优化策略： 1. P2P通信、长链接 2. 二进制协议 3. 码流压缩 4. 本地短路策略，本地-本机通 信优先&优化 5. 同时支持同步/异步 业务上的策略： 1. 并行请求，减少等待 2. 服务分层和接口聚合，减少 调用次数 3. 利用缓存，减少反复调用 4. 长调用等待，建议用异步消 息机制 新的关注点 应用 公有云、私有云、专有云…… 浏览器、Mobile、 TV、 IoT、AR、 VR、 …… API Mini service Micro service Serverless function 数据 业务 NoSQL 数据 系统 行为 日志 业务关 系型数 据 用户行 为 üServerless：从微服务到Serverless，应用被切分 得越来越细，更高资源利用和调度，更易弹性、演进 üAPI First : API成为云服务的核心要素，API驱动 微服务设计和构建 üCD Pipeline：以微服务为中心的自动持续交付流 水线 ü部署混合化 (Hybrid Cloud):企业使用混合的云环 境来运行应用，满足其经济性、敏捷性和安全等方面 的平衡 单体架构 Monolith application 微服务架构 Microservice application Serverless架构 Nanoservice without Servers 从微服务到Serverless的发展 Serverlesss :“Run code, not servers, reducing IT operational costs and deploy services faster” Serverless API Gateway Serverless Function Serverless Function Event Ingestion … 服务A (APIs) 存储 / DB 服务B (APIs) MicroserviceMonolith API GW+微服务的自然融合 API Gateway Product service Rating service Account service A/B Test Engine Instant Queue REST RPCRPC AMQPREST 服务聚 合/编排 Specified Open API single Endpoints， No Versions 前台 后台微服务 API GW让微服务更纯净、更好适配性、开放性： ü解决客户端/外部系统与微服务直接通信复杂的问题（网络性能、私有协议、 多屏重复逻辑等） ü解决微服务间聚合编排的问题 ü屏蔽微服务异构协议、框架、多版本、重构问题 微服务CD Pipeline Wait代码 提交 Wait软件 构建 Wait部署 验证 软件 发布 Weeks Mins Mins MinsDays Days Days 开发人员 生产环境 Triggers Compile ReleaseTest Release CheckDeployUpload PacketCode Check Package Hours Before After 微服务持续交付pipeline 全自动化 Stage标准化全在线化 可视化 应用持续交付存在诸多互相等待、协同和复杂的配合 最后的一些建议 1. 微服务化是个系统工程，技术保障和管理协同并进，架构& 框架、组织结构、业务流程都要配套 2. 微服务的构建、部署、运维能力要构建齐备，否则微服务 化之后复杂度倍增，效率并不能提升 3. 微服务不是银弹，有其使用的范围，对于数据处理为中心 的逻辑不适合微服务化 欢迎大家随时微信交流！ 欢迎有意愿者加入华为软件云平台大家庭！ QA 微信：miao-deer 邮箱：miaocaixia@huawei.com