《微服务架构深度解析与最佳实践.docx》由会员分享，可在线阅读，更多相关《微服务架构深度解析与最佳实践.docx（38页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、微服务架构深度解析与最正确实践第一局部：微服务深度解析微服务架构的开展过程简介微服务架构开展的五个关键时间节点微服务架构的开展趋势什么是微服务架构微服务架构的特点、优势和常见技术微服务的四个特点和六个能力微服务的优势常见的微服务技术框架Sping Cloud 与 Apache Dubbo Spring Cloud Alibaba第二局部：微服务最正确实践微服务架构不是银弹微服务系统适合的场景微服务带来的一些问题七个关键问题的应对策略如何合理拆分微服务遗留系统应该如何改造关于微服务对性能的影响怎么考虑拆分后的数据一致性系统和服务的高可用可伸缩如何实现拆分过程的测试和部署如何处理拆分后的运维和监控
2、如何处理最正确实践的总结参考材料微服务架构的概念，现在对于大家应该都不陌生，无论使用Apache Dubbo.还是 Spring Cloud,都可以去尝试微服务，把复杂而庞大的业务系统拆分成一些更小粒度且 独立部署的Rest服务。但是这个过程，具体应该怎么做？现有的条件下到底要不要做 微服务？服务拆分成什么粒度才是合适的？遗留的老系统需要如何考虑重构改造？有 哪些坑需要我们注意？系统怎么在分布式服务下实现数据的一致性和服务的高可用可 伸缩？拆分的过程中系统数量增多，测试、部署、运维、监控，又应该如何处理？for less-complex systems, the extra boggage r
3、equired to manageBase Complexitybut remember the skill of the team will outweigh any monolith/microservice choice 这个图x轴是系统复杂度，y轴是开发的生产力，我们可以看到: 在系统复杂度很低的时候，单体的生产力要高一点，这是因为拆分微服务，管 理这些服务的本钱增加了当复杂度开始增加，单体的生产力快速的降低，而微服务那么不太受影响，这是 因为复杂度大了，单体牵一发而动全身，各种耦合和相互影响太多 随着复杂度越来越高，微服务的低耦合开始减低了生产力的衰变，而单体架构 的生产力那么会降到
4、一个非常低的水平也就是说微服务应用在复杂度低的情况下，生产力反而比单体系统低。在复杂度高的地 方，情况恰恰相反。随着复杂度升高，单体架构的生产力快速下降，而微服务相对平稳，所以，复杂度越高 的业务系统，越适合使用微服务架构。搞清楚了微服务架构与单体架构的生产力的区别以后，我们再来看看微服务有哪些优 势，我总结了一下有以下几点： 服务简单：因为微小，所以简单，从一个大泥球，变成了很多个小而美的颗粒, 每个小颗粒职责单一，边界明确，可以通过简单组装完成大的功能，白然就比 之前的大泥球好处理得多。 灵活扩展：单体的情况下，只能通过增加机器，再部署多套单体系统做成集群, 前面加负载均衡来扩展；微服务以
5、后，我们会发现用户服务压力不大不用扩展, 订单服务压力大的时候多部署两台就可以了，这样我们就把扩展的方式从全部 优化到局部。 便于维护：如果一个系统有100个业务功能，依赖关系相互耦合到一起，那么 这就是维护的恶梦，这样的系统没有任何免疫力，修改任何个功能，都可能 会导致整个系统崩溃。微服务就简单得多了，每个服务自己出现问题，其他服 务不会直接受到影响。同时维护具体某个服务的人员，也不需要一上来就学习 全部的业务知识，比方用户服务模块的维护人员，只需要先学习用户服务的业 务就可以上手工作了。 独立演进：变成微服务以后，各个独立系统的内部设计和实现细节都被隔离开, 相互之间不受影响，只要服务间的
6、接口不变，大家就可以各自独立的开展自己 的系统，完成升级、重构、功能增强等等。 混合开发：各服务独立开发的另外一个好处就是，各个独立系统可以使用自己 的技术栈和研发模式，包括开发语言和工具、数据库存储和中间件等技术，这 样有助于试验和引入更先进和创新的技术，从一些个边缘服务开始尝试，技术、 工具、中间件、研发模式，孵化成熟以后，可以大范围推广，实现技术和研发 能力的持续更新换代，让研发组织保持长期的优势和活力，充分获得技术开展 的红利。 持续交付：微服务比单体系统简单明确，这样就便于我们利用自动化测试和自 动化部署来加速功能的迭代，配合CI/CD等基础设施，实现业务功能的持续交 付，保障研发能
7、够紧跟业务开展变化的节奏。常见的微服务技术框架具体怎么做微服务呢？我们先看看大家最常简单见到的微服务的务中，用户通过API网关访问系统的乘客、司机、出行三个REST服务，这三个服务 再通过REST访问计费、支付和通知三个服务。看起来很简单，也好理解，但是实际 的业务系统里，设计和实现一般会是这样：服务框架:我们可以选择用Spring Cloud或者Apache Dubbo,包括新兴的 Spring Cloud Alibaba,还有华为贡献的 Apache ServiceComb,蚂蚁金服的 SOFAStack , Oracle 的 Helidon, Redhat 的 Quarkus,基于 Sc
8、ala 语言和 Akka的Lagom,基于Grails语言的Micronaut,基于Python语言的 Nameko,基于Golang语言的go-micro,支持多语言混编的响应式微服务框 架Vert.X,腾讯开源的Tars,百度开源的Apache BRPC （孵化中），微博的 简化版Dubbo框架Motan等等。 配置中心：Apollo, Nacos, disconf, Spring Cloud Config,或者 Etcd、ZK、 Redis自己封装 服务注册发现：Eureka, Consul,或者Etcd、ZK、Redis自己封装服务网关：Zuul/Zuul2, Spring Cloud
9、 Gateway, nginx 系列的 Open Resty 和 Kong,基于 Golang 的 fagongzi Gateway 等 容错限流：Hystrix, Sentinel, Resilience,或者直接用Kong自带的插件消息处理：Kafka RabbitMQ、RocketMQ,以及 Pulsar,可以使用 Sping Messaging 或者 Spring Cloud Stream 来简化处理 链路监控与日志：开源的链路技术有CAT. Pinpoint.Skywalking.Zipkin. Jaeger 等，也可以考虑用商业的APM （比方听云APM. OneAPM. App
10、Dynamic等）， 日志可以用ELK认证与授权：比方要支持OAuth2. LDAP,传统的自定义BRAC等，可以选 择 Spring Security 或者 Apache Shiro 等Sping Cloud 与 Apache DubboSpring Cloud AlibabaSpring Cloud是一个较为成熟的微服务框架，定位为开发人员提供工具，以快速构建分 布式系统中的某些常见模式（例如，配置管理，服务发现，断路器，智能路由，微代理, 控制总线，一次性令牌，全局锁，Leader选举，分布式会话，群集状态）。其技术栈 大致如Spring Cloud生态HystrixHystrixMET
11、FLIX OSS ZuulArcholusSpnng Cloud 2ooKoQpQfSpring Cloud Sleuth以看到很多组件都是由Netflix贡献的。而Apache Dubbo定位是款高性能、轻量级的开源Java RPC框架，它提供了三大 核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。 所以，我们可以看到Dubbo提供的能力只是Spring Cloud的一局部子集。同时Dubbo项Fl重新维护以后，捐献给了 Apache,工程的导师就是Spring Cloud的 核心人员。自这时候起Dubbo工程就开始在适合Spring Cloud体系，结果就是
12、Alibaba也基于自己的系列开源组件和技术，实现了 Spring Cloud Alibaba,并顺利 从 Spring Cloud 孵化器毕业 详见: s:/spring.io/projects/spring-cloud-alibabaSpring Cloud Alibaba致力于提供微服务开发的一站式解决方案。此工程包含开发分布 式应用微服务的必需组件，方便开发者通过Spring Cloud编程模型轻松使用这些组件 来开发分布式应用服务。主要功能和开源技术栈： 服务限流降级(Sentinel)：默认支持 WebServlet WebFlux, OpenFeign、 RestTemplate
13、 Spring Cloud Gateway, Zuul, Dubbo 和 RocketMQ 限流降级 功能的接入，可以在运行时通过控制台实时修改限流降级规那么，还支持查看限 流降级Metrics监控。 服务注册与发现(Nacos)：适配Spring Cloud服务注册与发现标准，默认集 成了 Ribbon的支持。 分布式配置管理(Nacos)：支持分布式系统中的外部化配置，配置更改时自动 刷新。 消息驱动能力(Apache RocketMQ)：基于Spring Cloud Stream为微服务应 用构建消息驱动能力。分布式事务（Seata）：使用GlobalTransactional注解，高效
14、并且对业务零 侵入地解决分布式事务问题。可以看到，基本上功能都比拟完备了。第二局部：微服务最正确实践微服务架构不是银弹管理的常识一书里说，管理的核心是不断的解决（推进工作过程中出现 的各种）问题。同样地，我认为架构的核心那么是不断的解决（系统设计实现 与演化过程中的各种）问题。Fred Brooks在人月神话里说，“没有银弹”，现在依然成立，微服务也并不是只有 优点，没有副作用，把系统拆分了了很多局部，每一个局部简单了，但是整体的关系变 复杂了。前面介绍了那么多微服务的特点和优势，以及相关技术，我们再来分析一下微 服务存在的问题，进而讨论什么场景适合使用微服务，什么场景不适合，以及最正确的实
15、践方式。微服务架构首先是个分布式系统架构。分布式系统的开展由来已久，但是近年来产生 了理论和实现的大爆发。究其原因：分布式系统的开展得益于廉价pc硬件使得堆机器成为可能，而单机的本钱 /容量是非线性的，所以分布式的核心是线性的水平扩展整个集群的功能，以及带来的 协调机制，管理复杂度，数据和状态一致性，容错和故障恢复，容量与弹性伸缩，这些 通用性的基础能力建设。简单的翻译一下：单个机器堆资源，升级CPU内存加大一倍，想要增加一倍的处理能 力且本钱不超过一倍，不仅很难、而且不现实了。这样，我们就需要思考怎么通过进一 步对于系统里不同功能的局部，拆解开，单独扩展这些能水平扩展的局部，从而在控制 本钱
16、的前提下，提升整个系统的处理能力。另外，我们现在都知道，设计系统如果对可靠性，可用性有非常高的要求，那么需要先 假设上下游都是不可靠的，依赖的基础设施和网络也是不可靠的，这样就考虑分布式后 的分片、复制、故障转移、灾难恢复等，分布式系统下，我们可以对系统的不同性质的 节点、不同可靠性可用性要求的组件，做针对性的单独处理。很多系统看起来是分布式的，其实是一个大单机。很多系统看起来是微服 务的，其实是一个大单体。就像人月神话里说的，往己经延期的工程，加人手，可能会导致更延期。问题不是出现 在应不应该加人，或者应不应该使用分布式上。而是实施的人，没搞清楚关键。比方系 统拆成分布式或微服务，然后某个关
17、键地方依然卡住了业务流程，可能整体还不如单机 的，扩展性失效，多加机器还不如单机。为什么？因为如果希望用多个机器来扩展业务，最后发现各个机器上运行的程序没有划清楚边界 职责，多个机器合起来并不比单个机器有更大处理能力，这就是一个大单机。同样的，如果我们拆分了很多更小独立的服务，但是一个业务请求进来，还是在一些地 方被卡住，导致有一些瓶颈使得整个拆分后并不比之前有整体的改进，那么其实是费力 的做了一个大单体系统。所以合理的拆分微服务，使得我们能够更好的扩展系统是关键，同时如果业务简单，流 量不大，不扩展也可以很好的应对，系统对于可用性和一致性要求也不是特别高，那么 分布式和微服务，也不是必须的。
18、微服务系统适合的场景以下几类系统，比拟适合使用微服务架构，或者使用微服务架构改造: 大型的前后别离的复杂业务系统后端，业务越复杂，越需要我们合理的设计和 划分，长期的维护本钱会非常高，历史包袱也很重，这个问题后面会详谈。 变化开展特别快的创新业务系统，业务快，就意味着天天要“拥抱变化”，每一块 的业务研发都要被业务方压的喘不过气，不做拆分、自动化，一方面研发资源 永远不够用，活永远干不完，另一方面不停的在给系统打补丁，越来质量越低, 出错的可能性也越来越大。 规划中的新大型业务系统，如果有能力一开始就应该考虑做微服务，而不是先 做单体，还是开展到一定的阶段再做改造，改造一定是伤筋动骨的大手术，
19、虽 然我们可以采取一些策略做得更平滑，但是本钱还是比拟高的。 敏捷自驱的小研发团队，拥抱新技术，可以直接用微服务做系统，不但的通过 快速迭代、持续交付，经过一定时间的尝试和调整，形成自己的微服务实践经 验，这样在团队扩大时可以把好的经验复制到更大的团队。反过来，以下儿类系统，不太适合一开始就做微服务，小团队，技术基础较薄弱，创业初期或者团队新做的快速原型，这个时候做微 服务的收益明显比单体要低，快速把原型做出来怎么方便怎么来，用团队最熟 悉的技术栈。.流量不高，压力小，业务变化也不大，单体能简单搞定的，就可以先不考虑微 服务，不考虑分布式，因为分布式和微服务带来的好处，可能还缺乏以抵消复 杂性
20、增加带来的本钱。 对延迟很敏感的低延迟高并发系统，低延迟的秘诀就是离io能多远就多远，离 cpu能多近就多近，分布式和微服务，导致增加了网络跳数，延迟就没法降低。 技术导向性的系统，技术产品，这类产品跟业务系统不同，常规的业务系统研 发方法不是太适合。微服务带来的一些问题hris Richardson 在 :提到了微服务的几个缺乏:服务大小：微服务强调了服务大小，有人强调服务要大一点，也有人愿意 采用小服务。需要注意这只是一种选择，微服务的目的是有效的拆分应用，实 现敏捷开发和部署。 进程通讯：微服务应用是分布式系统，山此会带来分布式固有的复杂性。开发 者需要在RPC或者消息传递之间选择并完成
21、进程间通讯机制。相对于单体式 应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些, 需要考虑RPC的超时、重试、失效策略，或者消息服务不可用，堆积堵塞等 问题。 数据库拆分：数据库事务对于单体式应用来说很容易，因为只有个数据库。 在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式 事务并不一定是好的选择，不仅仅是因为CAP理论，还因为很多中间件并不支 持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了 更高的要求和挑战。 测试复杂度：比方采用流行的Spring Boot架构，对一个单体式web应用，测 试它的RESTAPL是很容易的事情。反
22、过来，同样的一个业务场景，需要测试 启动和它有关的所有服务，这些服务在不同的进程，所以变得尤为复杂。 服务依赖关系：微服务架构模式应用的改变将会涉及多个服务。比方，假设你 在完成一个案例，需要修改服务A、B、C,而A依赖B, B依赖Co在单体 式应用中，你只需要改变相关模块，整合变化，部署就好了。比照之下，微服 务架构模式就需要考虑相关改变对不同服务的影响。比方，你需要更新服务C, 然后是B,最后才是A,幸运的是，许多改变一般只影响一个服务，而需要协 调多服务的改变很少。特别是，如果要处理的服务间依赖是个网状关系，那 么很可能导致，我们修改A时，考虑到了会影响BCDEF这几个服务，但是漏 掉了
23、影响系统K,导致上线以后发现K的局部功能无法使用了。部署复杂度：部署一个微服务应用也很复杂，一个分布式应用只需要简单在负 载均衡服务后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据 库和消息中间件等基础服务。而一个微服务应用一般由大批服务构成。例如， 根据Adrian Cockcroft, Hailo有160个不同服务构成,NetFlix有大约600个 服务。每个服务都有多个实例。这就造成许多需要配置、部署、扩展和监控的 局部，除此之外，你还需要完成一个服务发现机制，以用来发现与它通讯服务 的地址（包括服务器地址和端口）。传统的解决问题方法不能用于解决这么复 杂的问题。接续而来，成功
24、部署一个微服务应用需要开发者有足够的成熟部署 方法，并高度自动化。PeterLawyer有在川中提出， 微服务的几个问题： 服务形成信息障碍。 引入了额外的复杂性和新问题，例如网络等待时间，消息格式，负载平衡和容 错。忽略其中之一属于“分布式计算的谬误”。 测试和部署更加复杂。 整体应用程序的复杂性仅转移到网络中，但仍然存在。 细粒度的微服务已被批评为一种反模式。其实可以看到，大家的想法和分析都比拟一致，微服务架构带来的固有复杂性和人为复 杂性如何管理：1 .如何合理拆分微服务，粒度如何控制：对业务按粒度和边界拆解的问题，这决 定了我们的服务是不是合理，开发和维护是不是方便。核心思路是深入了解
25、业 务。2 .遗留系统应该如何改造，从哪儿下手，如何推动：改造遗留系统一般来说比重新做一个新系统更复杂，如何平滑的、最大代价的将老系统改造成微服务，也 是一个巨大挑战。本文将从这些问题的深度分析出发，阐述微服务架构落地的一些设计原那么和利弊取 舍，结合微服务架构过程的很多最正确实践经验，希望给读者带来一定的启发和思考，避 免在实际应用过程中走弯路，能够多快好省的落地实现微服务架构。内容涉及：1 .微服务架构的开展过程简介2 .微服务架构的特点与常见特性3 .微服务架构的常见技术与简单例如4 .微服务架构存在的一些问题5 .如何合理拆分微服务6 .遗留系统应该如何改造7 .怎么考虑拆分后的数据一
26、致性8 .系统和服务的高可用可伸缩如何实现9 .拆分过程的测试和部署如何处理10 .拆分后的运维和监控如何处理第一局部：微服务深度解析微服务架构的开展过程简介 2012年3月James Lewis 2014年3月 Martin Flowler关于微服务原那么的演讲全面介绍了微服务架构 2011 年5月威尼斯 2012年11月 Fred George 2016年4月 JonasBon6r会议提出微0质提出微服架构概念展出响应式微服务架构微服务架构开展的五个关键时间节点 “微服务”这个概念最早是在2011年5月威尼斯的一个软件架构会议上讨论并提出的，用于描述一些作为通用架构风格的设计原那么。3 .
27、拆分后的性能应该如何保障：性能有两个指标，关键是区分出来如何处理不同 特性的数据，关注不同的指标，做好优化和选型，针对具体细节具体对待。4 .怎么考虑拆分后的数据一致性，分布式事务的选取和取舍：多个服务间的业务 数据一致性的问题，事务是个需要重点考虑的问题，主要是考虑强一致性的分 布式事务还是可以使用最终一致的弱一致性。对于一般的业务，可能使用补偿 冲正类的做法，在业务允许的一定时间内数据到达一致状态即可，比方30s, 或者10分钟。5 .系统和服务的高可用可伸缩如何实现：高可用意味着系统稳定健壮，可伸缩意 味着弹性，资源有效使用，如何做到无状态、不共享，是实现可高用可伸缩的 关键。6 .拆分
28、过程的测试和部署如何处理，怎么提升管理能力，降低风险：跨系统的协 作问题、测试的问题，这对于技术能力和研发成熟度较低的团队，会带来很大 麻烦。核心思路定义好业务边界、系统间接口与数据标准，提升自动化测试水 平。微服务架构由于拆分粒度较细，测试是个大问题。在保持每块职责单一的 同时，关键是保证接口稳定，做好自动化测试（特别是UT和接口的自动化） 和持续集成，尽量少全流程的人工回归测试。部署单元太多导致维护本钱上升 的问题，要管理的点多了，问题自然复杂了，核心思路是自动化部署与运维。7 .拆分后的运维和监控如何处理：怎么应对系统的故障，关键是保障核心技术的 指标，以及业务指标，做好预警报警，积累问
29、题、寻找根因，控制和杜绝低级 失误。七个关键问题的应对策略如何合理拆分微服务当一个系统服务化的时候，就会面临一个问题：如何进行服务的划分？怎么确定服务的 粒度？有没有一些可以参考的业界通用规那么？ 实际上服务划分的本质是对系统进行架构设计，服务的划分粒度没有绝对的过大或过小 之说，不同阶段的侧重点和思考的角度也不尽相同。创业初期的团队，过分的追求微服 务，为了“微”而微，反而会导致业务逻辑过于分散，技术架构过于复杂，团队基础设施 搭建能力弱，进而导致忽略了快速迭代交付产品的重要性，可能错失了市场机会。所以, 关于服务的划分不是对错的选择题，而是需要综合考虑各种外界的因素，所作出的一个 最适合的
30、决策，这些外界因素通常包括业务、技术债、开发、运维、测试这五个方面：业务所处领域的市场性质：对市场比拟敏感的工程，创业初期粒度应该尽量划 分的粗一些，先提供充足的弹药去占领市场，然后再去考虑对系统进行重构和 优化；与原有系统之间的关系：对于历史遗留的系统，需要做好新旧系统之间的边界 划分，防止过于激进、过大幅度的改造，应该采取小步快跑的方式，有节奏的 对老系统进行服务化改造；.开发团队的成熟度：服务化带来的技术风险应该提前进行评估，要考虑团队的承受度，用合适的人做适合的事，考虑团队需要有包括敏捷，包括Devops,包 括基础设施，运维和测试的自动化等基础能力； 基础设施的搭建能力：在进行细粒度
31、的服务划分时，要考虑团队是否有足够的 能力来支撑大量服务实例运行的运维复杂度，是否可以做好分布式的日志追踪 和服务的监控；测试团队的测试执行效率：过于细粒度的服务划分，如果测试团队不能通过自 动化测试、自动回归、压力测试、极限测试等手段来提高测试执行效率，必然 会带来测试工作量的大幅度上升，进而影响整个工程的上线周 期；You must be如果没有特别强烈的大规模水平扩展需求，拆分就没有必要，反而把问题搞复杂了。进 行服务化的拆分时，通常会先按照业务子系统先进行次划分，根据业务逻辑和数据的 关系划分为假设干个子系统，然后再考虑子系统内部是否可以再次进行拆分。至于拆分的 基本原那么，我推荐：
32、高内聚低耦合：这个已经提了很多了，简单说一下，就是要把强相关的局部， 总是会一起改动的局部，聚合到一起，相关性不大的局部拆开，可以参考DDD 中的一些方法。 粗粒度服务：服务的粒度要稍微的抽象和粗粒度一些，因为服务是基于业务场 景的抽象和设计，不能做成是直接把数据库的增删改查暴露出来成接口和方法, 而是应该隐藏这些细节，考虑清楚从业务和客户角度来看，哪些步骤和过程， 是必须封装起来的，细节隐藏掉，然后对外提供的就是粗粒度的服务，而在单体系统的时候，我们可以直接调用这些细节，无需过多考虑。虑。With two modules in the same process, its best to us
33、e many finegrained calls.-but when modules are remote, then favor few coarse-grained calls.遗留系统应该如何改造对旧系统进行改造，可以分为几个步骤：拆分前准备阶段，设计拆分改造方案，实施拆 分计划。下面是我的一些经验之谈。1）拆分之前先梳理系统关系和接口其中准备阶段主要是梳理清楚J依赖关系和接口，就可以思考如何来拆，第一刀切在哪 儿里，即能到达快速把一个复杂单体系统变成两个更小系统的目标，又能对系统的现有 业务影响最小。要尽量防止构建出一个分布式的单体应用，一个包含了一大堆互相之间 紧耦合的服务，却又必须
34、部署在一起的所谓分布式系统。没分析清楚就强行拆，可能就 一不小心剪断了大动脉，立马搞出来一个A类大故障，后患无穷。2）不同阶段拆分要点不同，每个阶段的关注点要聚焦拆分本身可以分成三个阶段，核心业务和非业务局部的拆分、核心业务的调整设计、核 心、业务内部的拆分。这三个阶段，第一阶段将核心业务瘦身，把非核心的局部切开，减 少需要处理的系统大小；第二阶段。重新按照微服务设计核心业务局部；第三阶段把核 心业务局部重构设计落地。拆分的方式也有三个：代码拆分、部署拆分、数据拆分。代 码直接表达了依赖关系，拆完就可以单独打包部署。但是有时候，我们可以通过控制一 些提供服务的开关，使用同一份代码和打包的程序，
35、部署多组进程，每组提供不同的服 务，这就是部署拆分，比方同一份代码，我们部署了 3组机器，A组5分提供订单服 务，B组2台提供用户服务，C组2台提供任务调度处理任务。数据拆分最复杂，涉 及到代码的调整，SQL和事务的分析和重构，数据库表的拆分甚至数据迁移，数据结 构的调整和数据迁移那么一般意味着需要停机维护。这三个方式，可以在适当的条件下选 择先做哪个操作合适。另外，每个阶段需要聚焦到一两个具体的目标，否那么目标太多 反而很难把一件事儿做通透。例如某个系统的微服务拆分，制定了如下的几个目标：1 .性能指标（吞吐和延迟）：核心交易吞吐提升一倍以上（TPS： 1000-10000）, A业务延迟降
36、低一半（Latency： 250ms-125ms） , B业务延迟降低一半 （Latency： 70ms-35ms）。2 .稳定性指标（可用性，故障恢复时间）：可用性=99.99%, A类故障恢复时间 =15分钟,季度次数v=1次。3 .质量指标：编写完善的产品需求文档、设计文档、部署运维文档，核心交易部 分代码90%以上单测覆盖率和100%的白动化测试用例和场景覆盖，实现可持 续的性能测试基准环境和长期持续性能优化机制。4 .扩展性指标：完成代码、部署、运行时和数据多个维度的合理拆分，对于核心 系统重构后的各块业务和交易模块、以及对应的各个数据存储，都可以随时通 过增加机器资源实现伸缩扩展。
37、5 .可维护性指标：建立全面完善的监控指标、特别是全链路的实时性能指标数据, 覆盖所有关键业务和状态，缩短监控报警响应处置时间，配合运维团队实现容 量规划和管理，出现问题时可以在一分钟内拉起系统或者回滚到上一个可用版 本（启动时间v=1分钟）。6 .易用性指标，通过重构实现新的API接口既合理又简单，极大的满足各个层面 用户的使川和需要，客户满意度持续上升。7 .业务支持指标：对于新的业务需求功能开发，在保障质量的前提下，开发效率 提升一倍，开发资源和周期降低一半。8 .核心人员指标：培养10名以上熟悉核心交易业务和新系统的一线技术人员， 形成结构合理的核心研发人才梯队。结果可想而知了，目前太
38、多了，反而没有目标。最后第一阶段只选择了稳定性作为最重 要的指标，先稳住系统，然后再在后面的阶段里选择其他指标，逐步实现各个目标。3）快速迭代，找到突破口，持续产出 大家都知道，敏捷开发之所以流行，就是因为小步快跑，快速迭代，实现对业务变化和 新需求的第一时间响应，这对快速开展变化的外部市场，以及KPI压力非常大的业务 部门非常重要。研发团队在系统改造过程也可以通过快速的阶段性产出，来证明团队的 技术能力和推进水平，增进互相的背靠背信任关系，为长期的顺畅合作打下坚实基础。 这方面，很多研发团队都想试图憋大招，搞个大工程，反而慢慢失去各个利益方的耐心, 最终把合作关系搞僵，吃了大亏。4）大胆假设
39、，小心求证，稳步上线凡事不破不立，拆分改造过程，我们每一次改动的地方，可能有多个不同的方案和路径, 具体选择哪一个最合适，这需要我们放开思路，大胆假设，充分吸收各方面的意见和想 法，然后小心谨慎的去测试，甚至在线上做验证，保障万无一失后，最后上线。5）保障质量，不断重构和改善现有设计和代码所有的事物都有产生，开展，衰退和消亡的过程。长期来看，软件系统的代码质量肯定 是会一直下降的，就像是人的身体健康，到了一定的程度，就会难以为继，需要甫构或 者重做。而不断的重构，改善现有的设计集合代码，就像是一直在保养身体，可以减缓 衰老，保证健康，增加寿命。6）取得领导和业务方的支持，过程和决策透明化拆分改
40、造看起来，没有给系统带来明确的可见收益，比方没有明显改进了用户体验，也 没有给系统新增了一个业务功能，但是却涉及到多方参与，付出劳动，这就必然会带来 很大的阻力，怎么办呢？还是从管理的常识一书里，我看到了一个很有道理的话：” 如果无法推动问题背后的人解决问题，那说明对问题挖掘的还不够深现代化的工作 教会我们，双赢/多赢是协作的唯一方法，也是可以持续的方法。搞清楚怎么才能推动 各个合作方的支持，怎么才能让领导同意，如果我们现在提的意见，他们不同意，那么 他们关心的点是什么，怎么把他们关心的点，纳入到这个工作范围里来，从而实现大家 可以达成一致来合作。同时需要注意的是，信息一定要透明，决策要公开，
41、让大家都直 接参与到这个过程，从而明确目标，一致前行。总结成48字箴言的“微服务拆分核心价值观”：1 .功能剥离、数据解耦2 .自然演进、逐步拆分3 .小步快跑、快速迭代4 .灰度发布、谨慎试错5 .提质量线、还技术债6 .各方一致，过程透明理想中的系统拆分改造效果（实际上一般最后都鸡飞狗跳）：关于微服务对性能的影响大家可以先思考2个问题：延迟（latency）和吞吐量（throughout）有什 么关系？延迟是响应时间么？先说一下延迟和响应时间，延迟是对于服务本身来说的，响应时间是相当于调用者来说 的（更多的内容可以参考数据密集型应用系统设计一书）：延迟（latency）=请求响应出入系统的
42、时间 响应时间（ResponseTime）=客户端请求开始，一直到收到响应的时间=延 迟+网络耗时理想状态下，延迟越低，吞吐越高，当然这是对单机单线程而言的，在分布式下就不成 立了，举个反例：比方从密云水库，拉一个水管到国贸，水流到国贸，需要1小时；如果再 拉一个水管到顺义，20分钟就可以。如果你在国贸用水龙头接水，你可以 单位时间接到非常多的水，这个数量跟你在过国贸还是顺义，没有关系，只 跟水库单位时间输入的水量/水压有关系。但是如果你在水管里放一个小球， 它从密云到国贸的时间是到顺义的时间的三倍，这样对于到国贸的这个水管 系统，延迟很高，但是系统的吞吐量跟到顺义的是一样的。同理，如果一个单
43、体系统，被拆分成了 10个服务，假如一个业务处理流程要经过5个 服务，这5个服务只要是每个吞吐量（TPS/QPS）不低于原先的单体，那么整个微服 务系统的吞吐量是不变的。相反地，我们通过服务变小，关系变简单，数据库简化，事务变小等等，如果5个系 统的吞吐都比原来的系统打，那么改造后的系统，整体的吞吐也比之前要高。那么这个 过程的副作用是什么呢？简单的说，就是延迟变高了，原来都是本地调用，现在变成了 5次远程调用，假设每 次调用的网络延迟在1-10亳秒（物理机房+万兆网卡可以很低，云环境下比拟高）， 那么延迟就会比之前增加增加5-50亳秒，而且前提是分布式下的请求，使用异步非阻 塞的流式或消息处
44、理方式，同步阻塞会更高，而且影响吞吐量。好在低延迟的系统要求 比拟少见，对于一般的业务系统来说，可以水平扩展的能力比延迟增加几毫秒要重要的 多。比方我们在淘宝或者京东，买个衣服，交易步骤的处理，在秒级都是可以接受的，如果 是机票、酒店、电影票之类的，分钟级以上都是可以接受的。再举一个现实的例子，某个公司从2016年起，就在做微服务改造，研发团 队规模不大，业务开展很快，基础设施没有跟上，自动化测试、部署都没有。 同时这个公司的主要核心业务是一个低延迟高并发的交易系统，微服务拆分 导致系统的延迟进一步增大，客户满意度下降。很快研发团队就发现了拆分 成了多个小系统以后，比单体更难以维护，继而采取了
45、措施，把局部微服务 进行合并，提高可维护性和控制延迟水平。对于分布式微服务系统的低延迟设计，更多信息可以参考Peter Lawyer的博客：怎么考虑拆分后的数据一致性微服务提倡每一个服务都使用自己的数据库存储，这就涉及到老系统的数据库拆分改 造。一般的数据库拆分，我们可以把不同业务服务涉及的表拆分到不同的库中去，这样 如果之前的事务中操作的两个表如果被拆分到了不同的数据库，就会涉及到分布式事 务。下面先解释一下分布式事务。我们知道ACID （原子性Atomicity、一致性Consistency、隔离性Isolation、持久性 Durability）定义了单个数据库操作的事务性，这样我们就能
46、放心的使用数据库，而不用 担忧数据的一致性，操作的原子性等等。由于数据库同时可以并发的给多个应用、多个 会话线程使用，这样就涉及到了锁，隔离级别和数据可见性等一系列工作，好在关系数 据库都己经帮我们解决了这些问题。但是在SOA、分布式服务化和微服务架构的大背景下，数据拆分到多个不同的库已经 是常态，这种改造或者设计中，同一个业务处理涉及到的关联数据生命周期可能要贯穿 到多个不同的数据库，如果没有事务保证，那么数据的一致性或者正确性就会收到破坏， 账就可能会错乱了，平台或者客户就会产生损失了。如何保证数据的事务性，那么是一个 非常有意思的话题。传统的数据库和消息系统一般都是支持XA分布式事务，通
47、过一个 TM事务管理器协调各个RM资管管理器，每个RM管理自己的本地事务，通过两阶 段提交2PC来保障一致。由于CAP的不可能三角约束下，我们大局部时候选择了从ACID到BASE （Basically Available 基本可用,Soft-state 柔性状态,Eventually consistent 最 终一致），这样分布式事务我们一般也从XA变成了 TCC （Try-Commit-Cancel）,把分布式事务的控制权从底层资源层（比方数据库） 挪到了业务实现层，从而通过释放数据库层的锁，来提升性能和灵活性。registerregisterregisterXAFESCARApplicat
48、ion如果直接操作数据库或者支持XA/JTA的MQ,可以使用XA事务。其他情况，可以 使用开源的分布式事务中间件。开源的分布式事务中间件有Apache ServiceComb Pack, Seata/Fescar, Apache ShardingSphere但是实际上，对大局部业务来说，性能远大于分布式事务带来的强一致性要求。更多时 候，我们可以先牺牲掉强一致性，甚至是准实时一致性，先让多个不同节点的服务，都 自己单独把业务执行掉。然后再通过定时任务去检查是否一致的状态，如果不一致，保 证可以从某个存储拿到原来的数据，重新执行即可。这时候其实是做了补偿的操作，补 偿会带来数据重复处理的情况，就是检查的时候没有执行，但是去补偿操作的时候，可 能已经在执行了。特别是我们使用异步的MQ之类的方式做业务处理和补偿，消息也可能由于MQ的机 制而重复。这时候我们只需要加上业务处理的塞等操