ServiceComb 微服务框架 杨波 ServiceComb 社区 / 华为开源软件能力中心 全栈生态：具有完整开源生态技术栈的解决方案，完全无商业Lock-in，支持平滑上云 配置中心生态 Others…… 微服务生态 ServiceComb 微服务解决方案 处理链 ServiceComb微服务解决方案 Java编程 （POJO/SpringM VC/JAX-RS） ServiceMesh ServiceCenter 是一个使用Go构造的、建立在etcd存储上的高性能、高 可用服务中心。 Java Chassis是一个由编程模型、运行模型、通信模型和服务契约四个 部分组成的微服务框架。 Saga 是一个微服务数据一致性解决方案。 ServiceComb的开放性设计 •Provider与Consumer具有完全 一致的开发体验 •通信模型与编程模型隔离，适 应不同业务场景需求 基于Pack模型的新构架 由 Alpha 和 Omega组成 •Alpha充当协调者的角色，主要负责对事务的 事件进行持久化存储以及协调子事务的状态，使 其最终得以与全局事务的状态保持一致，即保证 事务中的子事务全执行，或全不执行。 •Omega是用户程序侧代理，负责对网络请求 进行拦截并向Alpha上报事务事件，并在异常情

华为微服务框架 ServiceComb 姜宁 华为公司 技术与家 Building Microservice NO.1 深圳站 Cloud Native 架构下的 K8S 和微服务实践 INTRODUCTION 2018 Building Microservice NO.1 深圳站： Cloud Native 架构下的 K8S 和微服务实践 SPEAKER 华为公司 2018 Building Microservice NO.1 深圳站： Cloud Native 架构下的 K8S 和微服务实践 ServiceComb是一个什么样的项目？ 开源 微服务 框架 解决方案 侵入式 非侵入式 多语言 2018 Building Microservice NO.1 深圳站： Cloud Native 架构下的 K8S 和微服务实践 ServiceComb的来源 Microservice NO.1 深圳站： Cloud Native 架构下的 K8S 和微服务实践 ServiceComb项目介绍 • Java/Go Chassis • Java/Go 微服务框架 • 提供微服务注册发现以及限流降级，容错熔断等治理功能 • Service Center • 高性能，高可用服务注册中心 • Saga • 微服务数据一致性问题解决方案 •

反应式微服务框架 Apache ServiceComb设计思想 王启军 华为云 IoT⾸席架构师 王启军，华为云IoT首席架构师，曾担 任PaaS团队架构师，负责微服务框架 的开发。曾任当当网架构师，主导电 商平台架构设计；曾就职于搜狐负责 手机微博的研发。《持续演进的Cloud Native》作者，微信公众号“奔跑中 的蜗牛”博主。 p为什么微服务框架需要 Reactive Reactive pServiceComb 的 I/O 通信模型演进 pServiceComb API⺴关Edge Service p实践案例 为什么微服务框架需要Reactive？ • 微服务架构调用次数更多 • 更高的性能，规模效应 • 更好的用户体验 业界趋势 n Java 9中把反应式流规范以 java.util.concurrent.Flow 类的方式添加到了标准库中 n Spring 5 5对反应式编程模型提供了内置支持，并增加了新的 WebFlux 模块来支持反应 式 Web 应用的开发 ServiceComb Apache孵化的第一个微服务框架。 服务契约 怎么解决中台开发命苦的问题？ 多语⾔ 微服务运维 Mesher .NET 微服务 微服务 ServiceComb 微服务 Spring Cloud Node.js 微服务 PHP 微服务 其他语言

如果准备过程中出现问题，可以回滚 • 提交阶段不不允许出错 • 资源层⾯面提供保障业务侵⼊入性低 • 协议成本⾼高，并且存在全局锁的问题 ACID 与 BASE • ACID • 原⼦子性 （Atomicity） • ⼀一致性 （Consistency） • 隔离性 ( Isolation) • 持久性 (Durability) • BASE • 基本可⽤用（Basically ⼀一致性 （Consistency） • 隔离性 ( Isolation) • 持久性 (Durability) • Saga只提供ACD保证 • 原⼦子性（通过Saga协调器器实现） • ⼀一致性 (本地事务 + Saga log) • 隔离性 （Saga不不保证） • 持久性 （Saga log） 缺乏隔离性带来的问题 • 两个Saga事务同时操作⼀一个资源会出现数据语义不不⼀一致的的情况。 icroxchg-sagas.html 如何应对隔离性问题 • 隔离的本质是控制并发，防⽌止并发事务操作相同资源⽽而引起结果错乱 • 在应⽤用层⾯面加⼊入逻辑锁的逻辑。 • Session层⾯面隔离来保证串串⾏行行化操作。 • 业务层⾯面采⽤用预先冻结资⾦金金的⽅方式隔离此部分资⾦金金。 • 业务操作过程中通过及时读取当前状态的⽅方式获取更更新。 代码： https://github

如果准备过程中出现问题，可以回滚 • 提交阶段不不允许出错 • 资源层⾯面提供保障业务侵⼊入性低 • 协议成本⾼高，并且存在全局锁的问题 ACID 与 BASE • ACID • 原⼦子性 （Atomicity） • ⼀一致性 （Consistency） • 隔离性 ( Isolation) • 持久性 (Durability) • BASE • 基本可⽤用（Basically ⼀一致性 （Consistency） • 隔离性 ( Isolation) • 持久性 (Durability) • Saga只提供ACD保证 • 原⼦子性（通过Saga协调器器实现） • ⼀一致性 (本地事务 + Saga log) • 隔离性 （Saga不不保证） • 持久性 （Saga log） 缺乏隔离性带来的问题 • 两个Saga事务同时操作⼀一个资源会出现数据语义不不⼀一致的的情况。 icroxchg-sagas.html 如何应对隔离性问题 • 隔离的本质是控制并发，防⽌止并发事务操作相同资源⽽而引起结果错乱 • 在应⽤用层⾯面加⼊入逻辑锁的逻辑。 • Session层⾯面隔离来保证串串⾏行行化操作。 • 业务层⾯面采⽤用预先冻结资⾦金金的⽅方式隔离此部分资⾦金金。 • 业务操作过程中通过及时读取当前状态的⽅方式获取更更新。 Saga的实现⽅方式 • 集中式的实现⽅方式

apache.org [Github ] https://github.com/apache?q=servicecomb 服务间的通信 背景：为什么服务间通信重要？ • 每个微服务有自己的数据库（层） • 服务架构应用的质量很大程度取决于服务的拆分的高内聚，低耦合，不了解服务间通信，无法做出高质量的拆分。 不同的业务，涉及的不同的服务间通信有不同的要求 1. 关注事务性要求（ACID） 2 Saga同步qualification 1. 每个微服务对应自己数据层 2. 拆分经验：看业务，不看技术 3. 利用：saga, 事务性消息发布，最终一致性，同（异）步调用组合等微服务模式 [社区网站] http://servicecomb.apache.org [Github ] https://github.com/apache?q=servicecomb 步骤2 优化 先关注数据层的优化 1. 锁资格 - (锁库存-下订单) (锁库存-下订单) CP MySQL-MGR 高带宽 NvmeSSD-持久化配置 索引-加 锁 update-where 2. 库存缓存 AP Codis 3. 收藏数据 AP Codis 用户发请 求查库存 里列表 读缓存的 库存的列 表返回 用户对有库存 的房子发起下 单请求 再次查 询缓存 列表 锁定 资格 下单 （减库 存） 减 资 格 有库存 无库存 有资格

apache.org [Github ] https://github.com/apache?q=servicecomb 服务间的通信 背景：为什么服务间通信重要？ • 每个微服务有自己的数据库（层） • 服务架构应用的质量很大程度取决于服务的拆分的高内聚，低耦合，不了解服务间通信，无法做出高质量的拆分。 不同的业务，涉及的不同的服务间通信有不同的要求 1. 关注事务性要求（ACID） 2 Saga同步qualification 1. 每个微服务对应自己数据层 2. 拆分经验：看业务，不看技术 3. 利用：saga, 事务性消息发布，最终一致性，同（异）步调用组合等微服务模式 [社区网站] http://servicecomb.apache.org [Github ] https://github.com/apache?q=servicecomb 步骤2 优化 先关注数据层的优化 1. 锁资格 - (锁库存-下订单) (锁库存-下订单) CP MySQL-MGR 高带宽 NvmeSSD-持久化配置 索引-加 锁 update-where 2. 库存缓存 AP Codis 3. 收藏数据 AP Codis 用户发请 求查库存 里列表 读缓存的 库存的列 表返回 用户对有库存 的房子发起下 单请求 再次查 询缓存 列表 锁定 资格 下单 （减库 存） 减 资 格 有库存 无库存 有资格

同城双活的探索之路 • 未来的规划 大促的痛及混合云实践 业务服务层 资源层 分期乐 前端业务服务 桔子理财 鼎盛资管 …… mq管理系统 job管理系统 中台服务层 核心交易平台 风控审核平台 计算资源 (CPU) 存储资源 (内存|磁盘) 网络资源 (ip|端口|带宽) 中间件层 微服务框架 服务元数据管理 服务发布 服务订阅 消息中间件 消息元数据管理 情况无法应对 大促后机器闲置率高，资 源浪费巨大 混合云需求分析 机器资源按需 申请 01 接入层按url调 度流量 02 服务层set化的 路由策略 03 数据层读请求 上云，写请求 回自建idc 04 流量大户上云，顶住流量洪峰 机器器资源按需分配 接入层URL粒度流量调度 LB DNS app/browser Nginx-Proxy Nginx-Proxy Nginx-Proxy 安全防护 自建IDC 云IDC WAF WAF https://order.lexin.com/create https://order.lexin.com/query 服务化框架的单元化路由 自建IDC 云IDC 全站服务 registry 上云服务 混合云 自 建 机 房 all_service data(r/w) web data_proxy 云 机 房 read_service