常见的微服务的设计思考.pptVIP

微服务的设计思考 寇宇 2017/12 01 微服务的设计 02 微服务的架构模式 03 微服务的的监控 PART ONE 微服务的设计： 概念 PART ONE 一种架构风格、架构模式 服务能够独立构建、独立 部署、独立扩展 松耦合、单一职责、基于限界上 下文的一种SOA的落地实现 基于Devops，面向运维的架构 需要团队组织、文化的调整和完 善的自动化工具 实施中体现为：受业务驱动，不 断演进的架构 微服务 微服务的设计 常见误区： 我使用了Springboot或Dubbo等，所以我使用了微服务 微服务有助于提升应用性能 微服务只是一种新的架构模式，开发中改变下架构与设计方法就 可以做到微服务 我使用了 Docker容器，所以我使用了微服务 或者，我们没上容器，所以没法使用微服务 通过在微服务框架上开发微服务，仍可以保证事务的实现 PART ONE Monolithic 单体应用 分层架构 多种业务 功能耦合 MacroServices SOA类应用 粗粒度 共享数据 单体部署 MiniServices 细粒度 （Domain） 独立数据 独立部署 MicroServices 细粒度 （Feature） 独立数据 独立部署 微服务构建的演进 提高访问性 提高敏捷性 提高伸缩性 微服务的设计 PART ONE Do right things! 业务上真 的有需要吗？ 微服务不是“银弹”，并不适 合于每个应用和所有环境； 原则：最好不拆！ 何时采用微服务 业务响应速度已受到严重影 响，现有常规办法已无效果 现有架构下，再怎样加硬件 也无法改善应用指标 … 关键问题（一） ：该用微服务吗 PART ONE 准备工作 业务驱 动力 业务需 求 整体组 织架构 技术环 境 关键问题（二）：怎样设计出微服务 PART ONE 提取组件为服务的标准：通过区分”限界上下文”，形成微服务 标准1：识别整体架构内的”限界上下 文”,把不一致概念的分开。 标准2：处理优先级。在候选功能中，是 否是优先的功能提取？ 第二步：“扼杀旧应用” 不断地提取微服务，直到应用中全部的”限界上下文”都提取为微服务或其中所剩内 容已无必要再提取。 单体应用的分解方法： 拆 第一步：构建所有的新加特性作为微服务 不摧毁应用，也不加入新功能，而是使用 微服务方式实现新特性 集成新的微服务：anti-corruption layer， 隔离旧应用，提高扩展性 策 略 微服务的拆解粒度：how small is“small”? 最佳实践： 先粗后细：开始拆解时，很难一次性给出合适的粒度，可以先划分的粗些。 不断调整：当对服务有了更多认识后，会不断调整粒度，进行服务的进一步拆分、合并。 “类”与“服务”：类的数量不是粒度衡量的标准 服务实际上是指服务组件，被认为是承担特定职责的架构组件； 服务组件怎么实现和用多少类实现，要根据设计情况定； 确定服务粒度的基准测试 服务的范围与功能：分析服务提供的操作的内聚层次，拆分指示词，“并且”、“此外” 数据库事务：分布式的影响，ACID vs.BASE transactions ，是否服务粒度过细 分析服务编织的层次：编织会降低整体性能；影响可用性与健壮性。太多的编织意味着 服务粒度过细。请求响应能力与可靠性间的权衡 考虑组织文化、团队规模：Two-pizza Team,Cross 关键问题（三）：服务拆到什么程度 PART ONE 关键问题（四） ：反模式 PART ONE “数据驱动迁移”反模式： Functionality First, Data Last “共享”反模式：打破了服务间的限界 上下文 “超时”反模式 “Rest”陷阱 “静态契约”陷阱 … 因应业务发展而不断演变！ 商品 库存 价格 订单 会员 会员 购物车 促销 电商应用 . . . 由一个商业套件实现 全部应用功能 商品 库存 价格 订单 购物车 会员 促销 会员 电商应用 . . . 采用SOA模式，整合各定 制的单一分层应用 订单应用 开始按照限界上下文进行 服务拆分，但粒度较粗 . . . 微服务的设计： 服务拆分举例 PART ONE 拆 历经2-3年 历经3-4年 业务驱动力： 单体应用性能差，越来越难以通过硬件扩展来提升服务水平 难以快速开发、全量回归测试困难、难以快速部署上线，影响公司业务发展； 希望大幅提升订单的开发效率，易于快速开发、快速测试，降低复杂度； 业务需求： 接单：近200种场景的接单； 审核与资源处理：处理会员权益、促销资格、价格、优惠、库存等； 交易处理：支付相关操作； 查询：按多维度； 分发：同步必要的订单信息； 技术环境： 基于虚机的私有云环境； 处理单元化（可在分区内完成全部处理），利于跨机房部署； 微服务的