谈如何构建易于拆分的单体应⽤ 郑渊 腾讯公司 ⾼级⼯程师 ⽬ 录 微服务架构的困境与突破 01 建模：通过表象看本质 02 基于go-kit构建易拆分的单体应⽤ 03 总结 04 微服务架构的困境与突破 第⼀部分 微服务架构的困境与突破 01 Monolith to Microservices To move from Monolithic to Microservices Microservice） 1. 建模⽅法不只有领取驱动设计-DDD，还有⽤例驱动 设计-UDD等； 2. 并不是开始进⾏微服务拆分的时候才⽤到对应的建 模⽅法，在设计单体架构下同样也需要； ➢ 合适的时机选择合适的架构，⼤多数情况下单体先⾏， 尤其是对于创业公司或者⼤公司内部的创业项⽬ or ⼩项 ⽬ ➢ 选择基础设施相对完善的云平台和合适的业务框架 03 突破 建模：通过表象看本质 第⼆部分 ⽅案：尽量去映射，采⽤相似的命名，减少理解 上的差异！ 建模：通过表象看本质 09 业务架构图 ➢ 分层架构：变与不变 ➢ 实现⽅式：单体架构 vs 微服务架构 实战：基于go-kit构建易拆分的单体应⽤ 第三部分 实战：基于go-kit构建易于拆分的单体应⽤ 01 Go-kit Instruction https://github.com/go-kit/kit Go-kit is

Agenda • 为什么选 Go? • 单体和微服务怎么选？ • 单体到微服务何时转？ • 单体到微服务怎么转？ 为什么选 Go? • 节省服务成本 • 开发效率 • CI/CD简单 • 云原⽣友好 思想是多元的，观点是个⼈的 单体和微服务怎么选？ 单体的优点 • 开发简单 • 测试简单 • 部署简单 • 扩展简单 单体的缺点 • 难以理解和功能扩展 • 预留可能性 单体也有讲究 • 数据梳理清楚很重要 • 快速开发 • 快速交付 • 善⽤⼯具，降低出错 • 不增加成本并为业务发展留下扩展空间 单体到微服务何时转？ 什么信号标明该考虑转换了？ • 单体系统已过度复杂 - 体感 • 当前架构已不能满⾜业务发展需要 • 研发效率降低 • 持续集成、持续交付⽐较困难 • 团队⼈员已经⽐较多了 单体到微服务怎么转？ 充分调研必要性 • 技术选型 • 充分调研可⾏性 • 争取公司或者部⻔领导的⽀持 • 建微服务迁移核⼼团队，经验、执⾏⼒、⾃驱⼒ 现状分析 • ⼀团乱麻型 • 数据清晰型 • 分布式单体型 改造策略 • 初期挑选精兵，后期可成为⼦项⽬核⼼⼈员 • 由外向内，由边缘到核⼼ • 数据拆分、迁移和验证，可回滚 • fork请求，proxy验证 • 定期复盘过程，总结可复制套路

最多缓存 10 分钟的对局历史 - 不是根本解决方法 - 微服务单体化 - 腾讯文档团队《回归单体成为潮流？腾讯文档如何实现灵活架构切换》 - 更进一步优化：网络 RPC 改为函数调用，同时保留微服务架构 微服务——上线前压测 贵 微服务——火焰图 - 以实验层火焰图为例，业务逻辑仅占 CPU 10% RPC 变成内存调用才是单体的完全体 - 思路： - 网络流量 => 内存数据 - 基于 Protobuf v3 - 开源版： - https://trpc.group ; - https://polarismesh.cn - 内部版：tRPC 服务与北极星平台默认强绑定 单体服务——基于 tRPC 的灵活切换 // ---------------- // rerank.proto service FeedsRerank { rpc GetFeedList (GetFeedRequest) y() } func RegisterFeedsRerank(p pb.FeedsRerank) { feedsRerank = p } 封装 tRPC 函数，间接获取 client 单体化适配——隐藏函数 or RPC // ---------------- // client 端改为通过获取器获取 client // 客户端业务代码 // ...... // client

速进⾏开发？ 试想⼀下，要开发由 200 个“微服务”组成的云原⽣应⽤，会遇到哪些困难呢？ Localhost 时代 在单体应⽤的时代，对于开发者来说是极为友好的，�开发者使⽤本机运⾏应⽤，修改代码后实时⽣效，通过 浏览器访问 Localhost 实时查看代码效果。 单体应⽤和“微服务”应⽤不同，单体应⽤是 “ALL-IN-ONE” 组织⽅式，所有的调⽤关系仅限于在⾃身的类和函 数，应⽤对硬件的要求⼀般也不会太⾼。 ⼯作负载封装后，解决了开发过程应⽤的快速启动问题，开发⼈员只需要在本地 安装单节点的 Kubernetes 集群，例如 Minikube、Kind 等即可快速启动微服务应⽤。 但对于开发⼈员来说，原来单体应⽤的开发体验变得不复存在，由于应⽤很难在 Docker 容器之外运⾏，所以 每次代码修改，都需要经历以下步骤： 执⾏ docker build 构建镜像 执⾏ docker tag 对镜像进⾏标记 这直接拖慢了开发的循环反馈过程，每次修改，动辄需要数分钟甚⾄⼗分钟的等待时间。 Nocalhost - 重新定义云原⽣开发环境 Nocalhost 是⼀个云原⽣开发环境，希望让开发云原⽣应⽤像开发单体应⽤原始⼜简单。 Nocalhost 重新梳理了开发过程所涉及到的⻆⾊和资源： 团队管理⼈员 Nocalhost - 重新定义云原⽣开发环境.md 2021/1/20 3 / 7 开发者 应⽤ 集群

审计系统：扩展接口方便与不同公司审计系统打通。  通知系统：核心数据变更，或者操作，方便通过 SMS 系统打通，通知到对应人数据变更。 21 > Nacos 架构 Nacos 配置模型 背景 在单体架构的时候我们可以将配置写在配置文件中，但有⼀个缺点就是每次修改配置都需要重启服 务才能生效。 当应用程序实例比较少的时候还可以维护。如果转向微服务架构有成百上千个实例，每修改⼀次配 置要将全 Nacos 而演进。 什么是服务网格 要深入理解服务网格的概念，明确服务网格要解决的问题，以及认识服务网格带来的业务价值，需 要从应用架构的演进发展从头开始讲起。 单体架构向微服务体系架构的演进 近年来，随着业务体系不断发展和扩大，单体应用已经完成了向微服务架构的转变。应用按照功能 维度、业务领域进行了服务拆分，各个不同的业务团队专注于自身负责的服务，每个微服务独立迭 代且互相不影响。这种拆分 开发体 验。 凡事都有两面性，微服务在提升业务应用的迭代速度和敏捷性的同时，也给服务治理带来了更多的 挑战。原先是单体应用，所有的服务都在⼀个进程中，服务之间的调用就是方法调用，整条请求的 处理流程就在当前线程中，调试、排查问题非常方便。 改造成微服务架构之后，原先单体中的服务变成⼀个个独立部署运行的服务，方法调用变成了远程 调用。首先要解决的问题就是服务发现问题，Consumer 服务如何在运行时发现

粗粒度服务化，基础设施完善 CDN/页面缓存/静态站/缓存集群 移动后台旁路 流程double，冗余开始出现 移动后台单体 继续成长,瓶颈明显 后台日益庞大，业务冗余严重 N多业务排队上线，瓶颈明显 热点场景频发，影响单体稳定 2pizza团队，系统单体制约 商城 核心服务 业务 网贷 保险 基金 商城 财富圈 健康财富 加密 验签 拦截 校验 资金存管 账户中心 Pc Web 支付/钱包 外 部 系 统 流控 熔断 限流 版本 更多... 标签 用户 管理平台 产品 理财单 渠道 版本 5G 措施:剥组件,拆单体,合冗余 移动后台打散 轻业务上浮 重业务下沉 API接入 指标监控 配置管理 业务前置配置 日志 配置系统 安全控制 拦截、校验 接口签名 加解密 防刷 攻击类 接口缓存

微服务架构设计的现状 3 Service Mesh微服务设计 4 Service Mesh的框架介绍我过往的经历情况 类型：传统互联网 模式：CS/BS模式 类型：互联网 模式：单体模式 类型：游戏 模式：单体模式 类型：互联网金融 模式：微服务模式Java版本演进史 JDK J2ME J2SE J2EE Java SE 2004年 Java SE 5.0 2006年 Java Cloud的类库模式 Service Mesh的Sidecar模式Service Mesh：Istio架构Service Mesh：Linkerd架构Service Mesh： OCTO-Mesh架构为了解决单体的复杂度问题，我们引入微服务架构 为了解决微服务架构下大量应用部署的问题，我们引入容器 为了解决容器的管理和调度问题，我们引入Kubernetes 为了解决微服务框架的侵入性问题，我们引入Service

作者：王启军 日期：20190920 Security Level: 目录 1. 微服务拆分工具 2. 契约管理工具 Huawei Confidential 3 微服务架构的优势 因素 单体架构 微服务架构 交付速度 较慢 较快 故障隔离范围 线程级 进程级 整体可用性 较低 更高 架构持续演进 困难 简单 沟通效率 低 高 技术栈选择 受限 灵活 可扩展性 受限 灵活 务 规则3：归属同一微服务的表数量不低于5（作为参数可配置） 规则4：关联度大于10（作为参数可配置）的表归属同一微服务 Huawei Confidential 8 微服务拆分工具 单体应用 单体数据库 微服务数据库 A库 B库 服务A 服务B 步骤1：通过SQL的关联程 度、使用次数等，识别出 相关性最高的表划分成一 个微服务 微服务数据库 A库 B库 服务A 服务B 步骤2：通过表结构调整，

com/apache?q=servicecomb 助力文思海辉PHP语言系统实现 全微服务化架构 基于RFID技术的楼宇设施管理 遇到的问题 性能瓶颈稳定 性差 复杂度高不易 扩展 • 单体应用，功能耦合 • 新增功能影响现有业务，升级业务中断 • 业务增长对性能要求高，增加机器不能解决问 题 • 一个业务问题影响整个系统，风险高 基于微服务引擎Mesher功能将PHP应用接入微服务治理 运营渠道管理 运营管理门户 内容呈现接入 内容搜索 内容推荐 产品呈现 活动呈现 用户呈现接入 音乐播放控制 订单 用户行为 用户社交 华为音乐传统单体架构拆解成15+个微服务，基于CSE开发和治理 • 传统单体架构升级、维护、扩容成本高 • 架构不统一，有使用SpringCloud、Dubbo、Servlet等各 种架构，维护成本非常高 大系统小做缩短上线周期 • 快速、小批量交付价值需求

产品荣誉 无侵入微服务治理 无侵入式接入，提供注册发现、路由分 流、熔断限流等丰富治理能力。 精细化流量管控 支持不同维度的流量治理，并具备丰富 的流量管控能力。 架构平滑演进 支持单体架构向微服务架构、微服务架 构向服务网格架构平滑演进。 开放兼容 全面覆盖主流微服务开发技术选型，增 强、扩展开源服务网格。 异构应用统一治理 多框架、多协议、多语言服务的统一治 理，避免技术栈重复建设。 支持异构协议转换为 HTTP 协议 RESTFUL 接口，具备请求转换能力，有 效集成企业存量应用。 产品能力 云原生微服务统一管理平台，助力企业分布式技术架构演进。 轻舟微服务 微服务应用优势 巨石（单体）应用 代码级的依赖，容易出现代码冲突，以及影 响范围扩散，导致大量的沟通，开发效率低 随着规模增加 编译时间快速增加 代码级的依赖，需要全量测试 测试回归周期长 代码修改对整个应用有影响，需要全量测试 数据计算实时、稳定，降低大数据开发 与管理难度 建设覆盖产业全流程的经营分析体系， 提供数据监控、预警和决策支持 通过实时大屏、管理看板和固定报表等 数据形式，轻松掌握企业经营状况 客户需求： 单体架构难以支撑业务响应速度 信息不互通降低了用户体验 解决方案： 完成微服务中心的沉淀 建立敏捷研发流程 构建统一用户中心 客户收益： 提升效率，改善用户体验 简化运维，提升平台的稳定性 信息化资产增值并持续释放红利