⽥田晓亮 华为架构师 ⽥田晓亮 华为 架构师 8年软件⾏行业经验，曾就职于三星，2012年进⼊入云计算领域，对PaaS， DevOps，APM有深⼊入的研究和实践经验。⽅方案⽀支撑近千台VM中应⽤用部署管理监 控 2016年加⼊入华为担任架构师，负责微服务的Go语⾔言开发框架及Service Mesh设计 和落地，Go语⾔言微服务框架被华为5G核⼼心⺴⽹网络采⽤用，Service Mesh服务商⽤用上 • ⼀一种基础设施层，服务间的通信通过 Service Mesh进⾏行 • 可靠地传输复杂⺴⽹网络拓扑中服务的请 求，将服务变成现代的云原⽣生服务 • ⼀一种⺴⽹网络代理的实现，通常与业务服 务部署在⼀一起，业务服务不感知 • ⼀一种TCP/IP之上的⺴⽹网络模型 Application Service Mesh Transport Network Physical Application 对业务代码0侵⼊入 • 不适合改造的单体应⽤用 • 开发出开的应⽤用既是云原⽣生的⼜又具有独⽴立性 没有银弹 • 新的故障点 • ⼀一定程度的性能降低 • 侵⼊入式框架有更强的定制和扩展能⼒力 • 部署复杂性 • 简介 • 实现⼀一个Service Mesh • 使⽤用Service Mesh快速构建微服务 • ⽣生态与扩展 • Service Mesh在华为内部的技术演进 第⼀一代：基于Nginx的微服务代理

 技术选型：统一的微服务框架技术选型，涵盖微服务框架 、微服务流水线（CI/CD）、微服务自动化运维和部署框架  组织赋能：拉通设计、开发、测试和运维的跨团队培训、 技术方案试点、案例分享、 ServiceComb统一预警体系，不 同业务部门之间的合作和协同  服务化地图：业务部署上线后，对业务微服务API进行基 线化，并发布服务化地图，涵盖微服务的划分原则、微服务 流水线地址、微服务SLA指标等 统的同步服务调用，性能更高（吞吐量N倍+提升、时延降低 为原来的50%-）  轻量级、易集成：可以方便的与Spring MVC、Tomcat等 已有技术和容器集成，支持轻量级的standalone部署  服务治理：可商用的服务治理能力  成熟和商用支持：Apache孵化项目，公司内部大规模使 用，专职的团队支撑 微服务框架 RPC框架 跨语言：  gRPC  Thrift 端可以不导入服务 端的类库定义，双方互相解耦  微服务接口测试：测试基于流水线的API定义生成自动化测试用例， 防止开发本地随意修改API  微服务API依赖关系：通过微服务流水线编译、打包和系统集成 测试，识别并展示微服务API之间的依赖关系（我依赖谁、谁依赖我）  API变更管控：API变更邮件通知和审批，每日微服务流水线构建， 及时发现接口不兼容问题 实践-不同的微服务开发风格

够被独⽴立的部署到 ⽣生产环境、类⽣生产环境等。另外，应当尽量避免统⼀一的、集中式的服务管理机 制，对具体的⼀一个服务⽽而⾔言，应根据业务上下⽂文，选择合适的语⾔言、⼯工具对其进 ⾏行构建。 为什么要采⽤用微服务架构？ - Rebecca Parsons 让系统尽可能快的响应变化！ 初衷 • 服务足够小  • 独立运行  • 轻量级通信机制  • 独立的部署  • • 去中心化 • 要多小？  • 怎么部署？  • 出错怎么办？  • 如何保证一致性 玩得起微服务的条件 持续改进的⾃自组织⽂文 快速响 Tall enough 服 务 ⾃自 演 进 2009年 2012年初探微服务 2014年⿊黑暗时代 2015年服务治理 2016年新的征程 背景介绍 业务系统B 业务系统A 2012年新的需求 领域服务 服务C 服务D 业务系统A Librarian 业务系统B 服务E 服务F 微服务架构初步形成 那时的微服务 系统集成消除重复 ful API Restful API ⾃自动 化部署 特性 团队 它给我们带来了哪些好处？ 新业务C三个⽉月上线 领域服务 服务A 服务B 服务C 服务D 服务E 服务F Librarian 业务系统B 业务系统C 服务G 服务H

为⽤用户提供最终价值 • 每个服务运⾏行行在其独⽴立的进程中，服务间采⽤用轻量量级的通信机制协作（通常是基于RESTful API） • 每个服务都围绕着具体业务进⾏行行构建，并且能够被独⽴立的部署到⽣生产环境、类⽣生产环境等 Microservices – the new architectural style. Martin Fowler,Mar 2014 ...... Micro https://www.continuousdelivery.com/ • 缩短交付周期 • 降低发布⻛风险 • 质量量内嵌 组织协同 环境管理理 数据管理理 松耦合架构 反馈验证 持续集成/部署 内建质量量 微服务架构是松耦合架构机制的⼀一种实现 为什什么基于DevOps？ ● Communication ● Automation ● Measuring ● Sharing 测试策略略与应⽤用 应⽤用部署⾃自动化（包/映像/容器器） 容器器部署 映像部署 包部署 ⾃自动化“⼀一切” - 基础设施与部署流程 议题 • 微服务架构的核⼼心 • 微服务架构设计原则 • 微服务架构⽣生态系统 • 分布式系统复杂性 • 服务的治理理与维护 • 测试策略略与契约测试 • 持续交付流⽔水线 • 基础设施(私有云/公有云) • 持续集成/持续部署流⽔水线 • 团队的敏敏捷/⼯工程化实践

无法做到永远在线，大版本升级时，要停机中断服务 微服务化的应用构建和发布 产品发布计划 产品发布计划 产品发布计划 产品发布计划 开发 部署到生成 环境 部署到生成 环境 开发 开发 部署到生成 环境 部署到生成 环境 部署到生成 环境 开发 开发 bugs 旧版本持续运行 Speed & Safety 面临的问题 • 企业应用和互联网应用的不同？ 运行模型 还远远不止这些… 部署/启 动 日志/监 控 告警 诊断 治理/配 置 扩容 缩容 回滚 停止/卸 载 微服务运维生命周期 管理 创建 编码 编译 构建 部署 测试 验收 发布 删除 微服务开发生命周期 管理 从软件到服务 微服务治理 微服务部署平台（PaaS） 微服务开发 微服务基础治理

Serverless云平台（CCI） 微服务咨询 现状分析 适用性评估 试点实施 效果评估 经验固化 目标设定 培 训 （ 理 论 、 案 例 、 实 战 演 练 ） 应用管理平台（CAS） 生命周期管理 部署/卸载 启动/停止 升级/回滚 灰度发布 弹性伸缩 微服务运维 应用告警 日志分析 全链路拓扑 SQL分析 调用链 立体监控 方法追踪 事务洞察 微服务治理 负载均衡 限流/降级 伙伴 （软通、中软、幸宜、博思、医 信、……） 工具（CPE） 设计和开发 构建 测试 发布上线 监控运维 部署 流 水 线 （ 持 续 集 成 、 持 续 交 付 ） 扩展插件： Eclipse等 扩展插件： 静态检查等 扩展插件： 三方部署系 统 扩展插件： 客户测试系 统 扩展插件： 客户自有仓 库 扩展插件： 客户自有监 控 开发者生态 开源社区 in any infrastructure • 开发者不需要知道应用部署到容器还是虚机中，只需要像过去一样开发应用 • Java，Go，Nodejs等语言可部署到ARM，x86不同的基础设施中 • 完善的自动化促使组织能够管理大规模，快速的部署应用实例，应对业务流量，需求的变化 源码 软件中心 流水线 构建 归档 部署 配置中心 java python go nodejs php

Mesh的思考及在华为云 的实践 田晓亮 6/30/2018 9年软件⾏业经验，曾就职于三星，2012年进⼊云计算领域，对 PaaS， DevOps，APM有深⼊的研究和实践经验。⽅案⽀撑近 千台VM中应⽤部署管理监控 。华为云微服务引擎Mesher作者。 华为 架构师 田晓亮 website: http://servicecomb.incubator.apache.org/ gitter: https://gitter 6/30/2018 什么是Service Mesh • 一种基础设施层，服务间 通信通过Service mesh进 • 一种TCP/IP之上的网络模 型行 • 一个轻量的网络代理，与 业务部署在一起 • 可靠的传输复杂网络拓扑 中的服务请求，将服务变 为现代的云原生服务 Website: http://servicecomb.incubator.apache.org/ Gitter: Istio CSE Admin API • 独立监听端口 • 微服务健康 • mesher版本 • 路由信息 • Prometheus格式Metric数据 6/30/2018 透明的平台体验 • 部署容器应用时只需勾选以启用Mesher 6/30/2018 背后发生了什么？ • 为应用容器设置环境变量http_proxy • 为mesher设置CSE地址（注册中心， 配置中心） • 为mesher对接APM

微服务的“微”暗示了服务的大小，但实际上微服务架构对构成的服务实例并没有大小方面的要求。 微服务的微 微服务的两个“谬论” n 服务之间是强隔离的。 n 微服务是大型系统的唯一选择。 解耦合 独立开发部署 架构、组织、流程 微服务架构定义“三步法” 微服务拆分方法 微服务拆分-指导原则 拆服务-单体重构的节奏 服务分解的四大障碍 1、网络延迟 2、同步通信降低了可用性 3、跨服务的数据一致性 第二，编写整洁的代码和使用自动化测试至关重要，因为这是现代软件开发的基础。 n 第三，关注微服务的本质，即服务的分解和定义，而不是技术，如容器和其他工具。 n 第四，确保你的服务松耦合，并且可以独立开发、测试和部署，不要搞成分布式单体，那将会是巨大的灾难。 n 第五，也是最重要的，不能只是在技术上采用微服务架构。拥抱DevOps的原则和实践，在组织结构上实现跨 职能的自治团队，这必不可少。 还必须记住： 故障和问题 线上故障“画像“ 系统稳定性指标 可监控设计 同步调用下-无线程池隔离 同步调用下-线程池隔离实现方法 快速失败-超时 快速失败-时间窗口 快速失败-超时重试次数 区分部署和上线 常规系统保障流程 没有不出问题的系统 什么是混沌工程 混沌工程 故障注入 故障测试的区别 总结 工具 知识 经验 参考书籍