务验收规范、微服务运维和治理规范…  技术选型：统一的微服务框架技术选型，涵盖微服务框架 、微服务流水线（CI/CD）、微服务自动化运维和部署框架  组织赋能：拉通设计、开发、测试和运维的跨团队培训、 技术方案试点、案例分享、 ServiceComb统一预警体系，不 同业务部门之间的合作和协同  服务化地图：业务部署上线后，对业务微服务API进行基 线化，并发布服务化地图，涵盖微服务的划分原则、微服务  微服务API设计：支持Swagger API规范  开发方式：支持透明RPC、Spring MVC风格的微服务开发  编程模型：同时支持同步、异步的编程模型  性能：支持原生的Reactive模式（EventLoop），相比于传 统的同步服务调用，性能更高（吞吐量N倍+提升、时延降低 为原来的50%-）  轻量级、易集成：可以方便的与Spring MVC、Tomcat等 已 服务治理：可商用的服务治理能力  成熟和商用支持：Apache孵化项目，公司内部大规模使 用，专职的团队支撑 微服务框架 RPC框架 跨语言：  gRPC  Thrift  ServiceComb Java语言：  Dubbo  Motan LB 内置LB： 客户端负载均 衡 外置LB： Nginx、 Ribbon SLB 注册中心 配置服务：  Zookeeper  etcd

负载均衡配置固话在配置文件中， 节点操作需要人工上系统操作增减 节点 配置中心监听方式 客户端主动监听配置更新，配置秒 级生效，新扩容服务主动拉取全量 配置，流量接入时长缩短3分钟+ 配置名字服务 配置IP方式 服务端下发文件更新配置，更新配 置生效时间长，由于需要预先知道 负责均衡集群的机器信息，扩缩容 需要等元信息同步以后才能接入流 量，扩容流量接入时间长 负载均衡节点对接名字服务 虎牙负载均衡 虎牙负载均衡部署的机器一台机器上可能存在数百的配置，每次节点生效需要重新 reload配置，且节点新增或删除需人工上系统操作配置，配置生效对服务会有中断 配置IP方式 配置名字服务 客户端主动监听名字服务更新，节 点变更秒级生效 负载均衡配置固话在配置文件中， 节点操作需要人工上系统操作增减 节点 基于Nginx dyups模块的动态上下线 • 基于名字服务感知节点变化快速变更节点 • 基于nginx 微服务架构中基于DNS的服务注册与发现 背景 公司内部注册中心比较多，常见的有zookeeper、 ectd、consul、eureka等。服务注册通常有三种： 自注册、第三方注册、注册中心主动同步，异构微 服务相互调用困难；公共DNS不稳定，解析结果生 效慢，解析失败率高；DNS无法提供内网环境的就 近接入能力，内部服务调用无法实现就近访问。 目标 DNS解析成功率 100% 公共DNS分钟级生效

活动数据，消费者数据，媒体 数据，车联网数据等，全渠道 数据收集追踪，建立数据分析 模型，辅助业务的决策优化 大数据分析 及应用 线上数字化布局 线下数字化布局 车联网及线下店端消费者旅程与线上消费 者旅程相结合，设计多种跨渠道跨屏互动， 引导进店消费者通过扫码，配车，留资等 行为整合线上数据 利用人脸识别等多种技术及平台，通过可 配置用户聚类评级模型和数据处理算法， 实现消费者深度洞察，提高销售线索质量 外部接口标准化 • 营销能力标准化、营销形式个性化 标准化 • 线索清洗评分智能化、智能分流 • 自动化个性精准营销 • 自动化投放追踪 • 营销内容自动分发 • 智能客服 智能化 • 移动端优先、用户体验优先 • 易使用、培训便利化 • 管理多级可视化 • 系统易维护、易扩展开发 便利化 数字营销平台 6 github.com/apache?q=servicecomb servicecomb 用 安全组隔离 安全组隔离 安全组隔离 ELB C端流量 8 github.com/apache?q=servicecomb servicecomb.apache.org 以微服务方案为底座的服务化改造 主机厂CRM运营 经销商端销售助手 主机厂 呼叫中心坐席 CRM静态站点 #N （Vue 2.5, 支持 PC/移动端/微信H5) 域名：https://crm.exeedcars

Syncer是一个多服务中心的同步工具，对应用程序透明。专为大型微服务架构设计，实现不同的微服务技术栈实现的微服 务业务可以进行数据通信，未来可支持跨云的数据通信支持 • 项目地址：https://github.com/apache/servicecomb-service-center/tree/master/syncer Syncer - 融合异构、多服务中心的同步工具 gossip 协议 Register Discover Syncer Register Instances of other SC SERVICECENTER A • 开发计划 - 支持动态连接集群 - 支持跨数据中心能力 - 支持对接流行认证鉴权服务 [Website] http://servicecomb.apache.org [Github ] https://github.com/apache 项目地址：https://github.com/apache/servicecomb-fence 多种应用 场景支持 对接第三方认 证鉴权服务 多种认证 模式支持 简化模式 授权码模式 密码模式 客户端模式 灵活架构 模式 纯Session模式 纯Token模式 混合模式 • 开箱即用：提供了默认的Authentication Server、Edge Service、Resource Server实现，简化用户开发难度

com/apache/servicecomb-service-center/tree/master/syncer Syncer是一个多服务中心的同步工具，专为大型微服务架构设计，实现不同的微服务技术栈实现的微服务业务可以进行数 据通信，未来可支持跨云的数据通信支持。 •对应用程序透明。同步工具启停，不应该对应用程序的原有流程产生影响。 •为多服务中心提供对等网络。他们之间是松耦合的，成员可以自由加入与退出。 •对 https://github.com/apache/servicecomb-fence 微服务鉴权 多种应用 场景支持 对接第三方认 证鉴权服务 多种认证 模式支持 简化模式 授权码模式 密码模式 客户端模式 灵活架构 模式 纯Session模式 纯Token模式 混合模式 8 github.com/apache?q=servicecomb servicecomb.apache.org https://github

Building Microservice NO.1 深圳站： Cloud Native 架构下的 K8S 和微服务实践 异步性能支持 • 基于Vertx提供的异步内核 • 保持高性能的同时支持同步调用方式 • 将通信线程不业务处理线程分离 • 操作级别线程池控制，支持隔离仓 • 支持多种异步编程接口 • CompletableFuture • RxJava • Reactive Metrics 子项 说明 微服务资源使用 CPU、ThreadCount、Heap、NonHeap 基本的资源使用状态 Consumer端 Latency、CallCount、TPS 包含操作级别和微服务实例级别 Producer端 waitInQueue、lifeTimeInQueue、 executionTime、Latency、CallCount、TPS 包含操作级别和微服务实例级别 event record event response 2018 Building Microservice NO.1 深圳站： Cloud Native 架构下的 K8S 和微服务实践 跨服务事务追踪 • 通过一个全局事务将这些子事务关联在一起 • 服务提供方通过Omega注入全局事务ID • 服务的消费方通过Omega获取全局事务ID Request Interceptor

解耦合 独立开发部署 架构、组织、流程 微服务架构定义“三步法” 微服务拆分方法 微服务拆分-指导原则 拆服务-单体重构的节奏 服务分解的四大障碍 1、网络延迟 2、同步通信降低了可用性 3、跨服务的数据一致性 4、上帝类 微服务的忠告 n 第一，要记住微服务不是解决所有问题的万能 “银弹”。 n 第二，编写整洁的代码和使用自动化测试至关重要，因为这是现代软件开发的基础。 第五，也是最重要的，不能只是在技术上采用微服务架构。拥抱DevOps的原则和实践，在组织结构上实现跨 职能的自治团队，这必不可少。 还必须记住：实现微服务架构并不是你的目标。你的目标是加速大型复杂应用程序的开发。 --Chris Richardson 容错 故障和问题 线上故障“画像“ 系统稳定性指标 可监控设计 同步调用下-无线程池隔离 同步调用下-线程池隔离实现方法 快速失败-超时 快速失败-时间窗口

分布式系统复杂性 • 服务的治理理与维护 • 测试策略略与契约测试 • 持续交付流⽔水线 • 基础设施(私有云/公有云) • 持续集成/持续部署流⽔水线 • 团队的敏敏捷/⼯工程化实践 • 端到端的⼯工具链 • API⽹网关 • 服务开发框架 • 测试验证框架 • 部署运维⼯工具 系统化的⼯工程 框架层出不不穷 多维度互相依赖 为什什么需要⽣生态系统? 微服务⽣生态系统 API⽹网关/Edge Service ⽀支撑层 基础设施 交付流⽔水线与⼯工程实践 CaaS/PaaS IaaS 微 服 务 开 发 框 架 ⼯工 程 实 践 与 规 范 持 续 交 付 流 ⽔水 线 端 到 端 的 ⼯工 具 链 注册发现 监控 调⽤用链 路路由 授权认证 ⽇日志聚合 容错 集中配置 基础设施 业务层 - 聚合服务 - 基础服务 接⼊入层 • 流量量限制 • 调⽤用统计 Service ⽀支撑层 基础设施 交付流⽔水线与⼯工程实践 CaaS/PaaS IaaS 微 服 务 开 发 框 架 ⼯工 程 实 践 与 规 范 持 续 交 付 流 ⽔水 线 端 到 端 的 ⼯工 具 链 注册发现 监控 调⽤用链 路路由 授权认证 ⽇日志聚合 熔断 集中配置 基础设施 接⼊入层 业务层 - 聚合服务 - 基础服务 • ⾯面向对象设计(名词/动词)


不同的业务，涉及的不同的服务间通信有不同的要求 1. 关注事务性要求（ACID） 2. 关注对性能的要求 举例：客户维护和订单是2个微服务，订单系统对性能有较高要求，所以可以考虑把购房资格信息从客户维护微服务同步到订单系统，改同步动作 对性能没有要求，对事务性有要求。 常见的服务间通信模式：同（异)步通信，API组合，基于MQ的异步通信 事务性： saga, 事务性消息发布（一次仅一次），分布式事务等 很易用的 Login House- order Realestate User- Center Customer-db Order-db Login-db Redis Redis Gateway Saga同步qualification 1. 每个微服务对应自己数据层 2. 拆分经验：看业务，不看技术 3. 利用：saga, 事务性消息发布，最终一致性，同（异）步调用组合等微服务模式 [社区网站] http://servicecomb SeviceComb优异的异步通讯模型，REST over Vertx。 2. 透明RPC模式+CompletableFuture。把异步继续进行。 3. 低超时+重试策略配置。“ 高可用”的定义？A跟a 的区别 à 客户端无异常。 4. Zuul VS edge-service（完胜）。 100并发 vs 20000 并发。 5. 生产环境需从最外层开始设置限流策略，并设置降级机制。 [社区网站] http://servicecomb

RPC还是REST，传输方式决定编程模型 2. 丌同开发人员熟悉丌同的编程模型 3. RPC、REST的治理如何迚行 4. REST性能低 5. Reactive还是同步 ServiceComb的同步 仅仅是指编程模型上的同步，跟网络通信无关 因为所有场景下网络操作都是异步的 •Producer •Consumer 整体线程模型 Producer 业务线程 业务线程 Eventloops Executor 线程 …… 线程 队列 Executor 线程 …… 线程 队列 …… Consumer 消费端，主要需要处理的问题是如何更 高效地将请求推送到对端去，然后拿到 应答信息。 透明RPC Consumer业务线程 Consumer Eventloop 连接 业务线程 write(composite buffer) Producer  丌同于消费者，生产者主要的工作就是等待消费者 的请求，在处理之后，返回应答 在这一端我们更加关注：“如何高效地接收和处理 数据”这件事情  同步模式下，业务逻辑不IO逻辑分离，且根据 “隔离仓”原则，为了保证整个系统更加稳定和高 效地运行，业务逻辑本身也需要在丌同的隔离的区 域内迚行。而这些区域，就是线程池。