1、云原生微服务架构设计方法与实践彭建华戴尔科技集团大中华区战略服务团队应用服务部云原生趋势云原生趋势技术正在改变各行各业1 IDC FutureScape：2018 年 10 月发布全球 IT 行业 2019 年预测-文档编号 US44403818经济愈发趋向于数字化经济愈发趋向于数字化竞争优势竞争优势数据软件成功意味着提供数字服务，由数据提供支持，并在多云环境中运行。60%（到 2022 年）全球 GDP 中占企业现状:从需求提出到产品化需要半年以上改进应用组合是第一要务去年未实现任何改进48%78%到到 2022 年，将有年，将有90%的新企业级应的新企业级应用使用云原生方法交付用使用云原生

2、方法交付到到 2022 年，将有年，将有70%的企业具有统的企业具有统一的虚拟机、一的虚拟机、Kubernetes 和多云环境管理和多云环境管理流程、工具流程、工具和具备这些技能的员工和具备这些技能的员工到到 2024 年，全球将有年，全球将有5亿亿云原生应云原生应用用由 Forrester Consulting 代表 VMware 进行的一项委托研究。“How Transformative CIOs Use Customer Experience to Differentiate&Deliver Results”，2020 年 2 月。IDC FutureScape 2020但云原生应用将很

3、快成为新标准但云原生应用将很快成为新标准什么是云原生？传统应用云原生应用应用开发周期3-6个月1-2周应用测试周期2-4周2-4天应用部署周期1-2周10-20分钟应用迭代周期6-12个月1次1天6-12次应用规模扩展纵向扩展，1-2周横向扩展，5-10分钟“敏捷”是企业能以多快的速度将想法落地成实际业务的能力（from idea to production）云原生带来的改变云原生带来的挑战现代应用挑战云原生体系组装非常复杂且耗时日常进行修补、版本控制和扩展以保持生产就绪状态保留现有的应用、技能和基础架构投资必须在私有、公有和边缘端的多个云环境中运行工作负载的同时完成这些工作。123在实际的多

4、云环境中在实际的多云环境中PaaS云平台现代应用挑战应用PaaS计算IaaS微服务存储网络云管理单体应用数据库商业软件应用云平台TanzuKubernetesCloudFoundry 将应用与运行环境解耦 支持多种开发语言 支持容器技术 支持微服务架构 自动化持续构建部署 实时监控，自动化运维 弹性伸缩，动态扩展 灰度发布，升级无业务中断 多租户隔离，基于角色控制访问 故障自愈，高可用性微服务架构微服务架构众多因素驱动IT走向微服务架构基础架构应用架构重型应用微服务物理/虚拟IaaS/PaaSIT业务从交易型转向交互型IT功能快速迭代开发需求IT系统水平扩展需求客户端的多样性IT系统持续发布需

5、求大数据技术推动业务智能化云计算及容器技术发展成熟什么是微服务架构微服务架构将单一的应用使用一套微型服务的方式来构建，这些微型的服务在各自的进程中运行并通过轻量级的进程通讯方式交互(通常是HTTP的API方式)。这些服务基于业务职能构建并能够由全自动的部署方式进行单独的部署，这些服务是去中心化的，并有可能由不同的开发语言使用不同的数据存储模式来构建。关键特征：关键特征：基于业务功能来划分 只在微服务中处理复杂业务逻辑 业务功能去中心化，各司其职 数据管理去中心化，分布式数据 微服务间轻量级的通讯机制 持续集成与持续发布 微服务之间需考虑失败可能性 微服务的可单独替换升级Data AccessS

6、erviceHTMLJavaScriptMVCServiceUI SpecialistsMiddleware SpecialistsDBAsBusiness CapabilityBusiness CapabilityBusiness Capability竖井式团队竖井式应用架构交叉式团队微服务应用架构微服务架构 vs 传统单体架构一体化架构一体化架构微服务架构微服务架构构建复杂/设计相对简单模块的依赖性由开发语言/开发框架/应用中间件决定应用更新周期紧耦合/无法快速迭代和部署伸缩能力有限，效率低下对新的开发人员而言比较友好，容易上手无法有效应对扩展性开发需要对于选定的技术路线的长期投资构建简单

7、/设计有挑战性模块依赖性由模块服务功能来定义应用更新周期松耦合/可以频繁迭代部署有效的高可伸缩性单独的模块对于新加入的开发人员而言不够直接具备可扩展性开发消除了对于技术路线的依赖性Data AccessServiceHTMLJavaScriptMVCService微服务总体架构RDBMSData and Messaging ServicesPaaSApplicationsMessagingBig DataMicroservice 1Microservice 2Microservice 3Microservice 4Microservice 5Microservice 6ERPI nt egra

8、t i onI nt egrat i onBat chBat chRESTRESTCRMRDBMSLegacy Systems In-Memory Data Grid.Microservice 7Microservice 8Bi g Dat a Bi g Dat a 微服务架构设计考量 立方体模型单体微服务X轴：多实例扩展Y轴：功能分解X轴：多实例扩展考量轴：多实例扩展考量服务注册与发现，去中心化外部集中式缓存，无状态化前后端分离，支持多终端Y轴：功能分解考量轴：功能分解考量以业务功能为分解的出发点过犹不及，考虑微服务的代价采用DDD-领域驱动设计Z轴：数据分区考量轴：数据分区考量数据归属于微

9、服务，去中心化避免分布式事务微服务之间只考虑最终一致性考虑是否需要采用CQRS模式领域驱动设计领域驱动设计Domain Driven DesignDomain Driven Design领域驱动设计模型领域驱动设计的最佳实践现代化的DDD最佳实践 第一步：Event Storming 事件风暴 第二步：Boris 业务关联梳理 第三步：SnapE 定义微服务 第四步：Slice Analysis 切片分析 第五步：Cloud Native Dev 云原生开发OKREventStormingBorisSnapESliceAnalysisCloud Native DevEvent Storming

10、 事件风暴与技术无关，由业务人员主导，技术人员参与，通过这个步骤，技术人员了解业务。梳理业务事件的flow，要做到使用业务语言对业务事件进行描述，业务人员和技术人员要统一采用业务语言。要问业务人员这个业务事件从何处来，做什么，输出去哪里，需要的业务数据从哪里拿，等等，这样就会带出更多的业务事件和外部模块。业务事件梳理充分后，对业务事件进行分组，业务和数据紧密相关的事件归并到一组，形成多个组，这些组就是候选微服务，它包含一个或多个 Aggregate。EventUserExternal SystemPainPointGroup事件用户外部系统痛点分组Boris 业务关联梳理与通信机制相关，但与技

11、术无关，对候选微服务之间以及与外部系统之间的业务事件和通信机制进行梳理。通信机制分三种：同步API（如REST,SOAP）；异步消息；其它（如DB操作，Email，SMS）。如果发现候选微服务之间的业务耦合紧密，可以考虑合并成一个。技术人员应该考虑在满足外部系统交互的前提下，怎么通信更合理。SnapE 定义微服务 定义每个候选微服务，整理出它的API(SYNC);PUB/SUB(ASYNC);Story;Data(Entity/VO);UI;Risk(Pain Point)。调整候选微服务，合并或者拆分，产生真正的微服务，主要考虑因素如下：职能类似或者技术实现类似的service candid

12、ate，可以考虑合并，但最好避免不同的业务牵连其中；业务交互过于紧密的service candidate，可以考虑合并；业务数据需要强一致性的service candidate，可以考虑合并，当然如果最终一致可以接受的话，就可以不合并；考虑service candidate的生命周期、更新速度、扩容大小，这三方面需求不一致的service candidate最好不要合并；有些service candidate可以用来隔离特定类型的潜在故障，或者隔离外部系统依赖，这些应该考虑以独立的微服务来实现；微服务确定后，开始考虑技术实现，如平台、框架、消息中间件、存储、缓存、辅助系统等等。Slice An

13、alysis 切片分析Slice 切片，指实现某一业务场景的业务flow，它可能由涉及多个微服务。根据团队规模，梳理出三五个可作为开发目标的Slice，并按照价值和难易度进行归类。不要按照微服务的维度进行开发，而应该按照切片的维度进行开发，因为一个微服务无法完成一个业务场景。遵循 Minimum Viable Product(MVP)最简可行产品原则，选择容易且价值高的Slice开始开发，并快速迭代升级。微服务开发要素1.1.基准代码基准代码一份基准代码，多份部署2.2.依赖依赖清单文件显式声明依赖关系3 3.配置配置在环境中存储配置，使用环境变量6.6.进程进程以一个或多个无状态进程运行应用

14、5.5.构建，发布，运行构建，发布，运行实现CI/CD管道，自动化构建、发布到运行环境4.4.后端服务后端服务应用消费服务，把后端服务当作资源9 9.易处理易处理可快速启动和优雅终止，并具备上下游容错能力8 8.并发并发支持多实例并发运行，跨节点横向扩展7.7.端口绑定端口绑定通过端口绑定提供服务，一般应将HTTP绑定到端口1212.管理进程管理进程后台管理任务当作一次性进程运行1010.开发开发/生产环境相同生产环境相同尽可能的保持开发，预发布，线上环境相同11 11.日志日志应用把日志当作事件流，使用标准输出15.15.认证和授权认证和授权考虑安全，暴露端点应受RBAC模式保护1313.A

15、PIAPI设计优先设计优先在开放服务之前，首先设计服务的API14.14.远程监控远程监控对应用的健康和性能状况进行监控云原生12要素https:/ 项目，改造优化一个集装箱实时库存系统：采用事件驱动架构收集设备相关事件并进行处理，根据历史数据和库存预测来制订空集装箱计划。推演集装箱设备状态，使得各地的设备状态可见，计算一段时间内不同位置、当前和未来的设备供需数据。原系统总体部署图原系统架构，在WebLogic上运行项目解决方案应用PAS(Tanzu TAS)PKS(Tanzu TKGI)Dell Tech App ServicesPaaS云平台IaaS(vSphere)倡导应用技术平台化战略

16、思维，采用戴尔科技提供的PaaS云平台+微服务应用服务组合 部署PAS/PKS云平台，基于PAS/PKS敏捷开发和自动化运维，提高软件生产效率 将 RTI 集装箱实时库存系统进行云原生改造，微服务化，容器化，往PAS/PKS云平台上迁移cfPaaS云平台规划与实施云平台规划与实施选择合适的PaaS云平台和服务组件，制定PaaS层架构方案，并负责实施。传统应用云迁移传统应用云迁移检查传统应用技术栈，修改相关代码和配置，打包docker镜像，部署到PaaS上运行。云原生应用设计开发云原生应用设计开发设计微服务架构，开发云原生应用，采用敏捷模式进行项目管理，快速迭代开发。计算存储网络云管理RTI 集装箱实时库存系统微服务微服务拆分最终微服务架构THANKS!