微服务的设计思考VIP专享VIP免费

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