微服务理解与实践.docx

《微服务理解与实践.docx》由会员分享，可在线阅读，更多相关《微服务理解与实践.docx（40页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、微服务理解与实践微效劳理解与理论微效劳架构的概念如今对于大众应该都不生疏无论使用ApacheDubbo、还是SpringCloud都可以去尝试微效劳把复杂而庞大的业务系统拆分成一些更小粒度且独立部署的Rest效劳。但是这个经过详细应该怎么做现有的条件下到底要不要做微效劳效劳拆分成什么粒度才是适宜的遗留的老系统需要怎样考虑重构改造有哪些坑需要我们注意系统怎么在分布式效劳下实现数据的一致性以及效劳的高可用可伸缩拆分的经过中系统数量增多测试、部署、运维、监控又应该怎样处理本文将从这些问题的深度分析出发阐述微效劳架构落地的一些设计原那么以及利弊取舍结合微效劳架构经过的很多最正确理论经历祈望给读者带来一

2、定的启发以及考虑防止在实际应用经过中走弯路可以多快好省的落地实现微效劳架构。内容涉及微效劳架构的开展经过简介微效劳架构的特点与常见特性微效劳架构的常见技术与简单例如微效劳架构存在的一些问题怎样合理拆分微效劳遗留系统应该怎样改造怎么考虑拆分后的数据一致性系统以及效劳的高可用可伸缩怎样实现拆分经过的测试以及部署怎样处理拆分后的运维以及监控怎样处理第一局部微效劳深度解析微效劳架构的开展经过简介效劳架构开展的五个关键时间节点“微效劳架构那么是由FredGeorge在2021年度的一次技术大会上所提出在大会的演讲中他讲解了怎样分拆效劳和怎样利用MQ来进展效劳间的解耦这就是最早的微效劳架构雏形。而后由Ma

3、rtinFowler发扬光大并且在2021年度发表了一篇著名的微效劳文章这篇文章深化全面的讲解了什么是微效劳架构。随后微效劳架构逐渐成为一种非常流行的架构形式一大批的技术框架以及文章涌现出来越来越多的公司借鉴以及使用微效劳架构相关的技术。2016年度4月Lightbend公司的创始人兼CTO、Akka的JonasBonr发布了一本小册子?响应式微效劳架构?讨论了基于响应式原理的微效劳架构和怎样将其用于构建可扩展可应对故障的隔离效劳并与其他效劳结合以形成一个严密的整体。十分值得一提的是在微效劳架构开展的经过中还有两位技术大牛的影响不可无视ChrisRichardson?POJOSINACTION

4、?与?微效劳架构的设计形式?的也是著名开源工程cloudfoundry以及eventuate的创始人他做了大量的微效劳架构相关的方法以及理论的探究这里有其大量的演讲材料以及视频。SamNewmanMartinFowler以及JamesLewis的Thoughtworks前同事?BuildingMicroservices?以及?MonolithToMicroservices?这两本的前一本中文版叫?微效劳设计?同时也是2021年度著名的推特论战?单体应用vs微效劳应用?的主角之一另外两人分别是Netflix的AdrianCockcroft以及Etsy的JohnAllspaw详细参见。微效劳架构的

5、开展趋势软件架构的开展趋势简单的讲可以分为这几个阶段详细介绍可以参见我的上一个文章?软件架构开展历程共享?或?高可用可伸缩微效劳架构基于Dubbo、SpringCloud以及ServiceMesh?一书单体架构最简单的架构风格所有的代码在一起部署到单个进程例如打包成一个war或jar就是通常讲的“大泥球。垂直架构随着业务的开展系统变得复杂通过构造化考虑大众发现对于大规模协同开发有效的控制系统规模以及交互难度需要将效劳进展垂直方向拓展。微效劳架构MSA微效劳架构风格将系统设计为一组低耦合的微效劳每个效劳独立的部署运行效劳间一般采用REST等方式通信同时采用自动化的测试运维等技术降低效劳拆分后的复

6、杂度。我们可以从Google的趋势图看到从2021年度起微效劳架构架构的热度就直线上升成为最热门的技术之一。从国内的情况来看一方面另一方面一直到如今每年度的QCon大会都会有微效劳架构版本跟大众共享最新的微效劳架构知识以及理论经历。什么是微效劳架构讲了这么多那么到底什么是微效劳以及微效劳架构呢详细包含如下特征组件以效劳形式来提供微效劳也是面向效劳的提倡用可以独立部署的效劳来作为组装业务才能的组件而不是类库的形式。这样需要明确定义组件间的接口以及通信协议。微效劳架构的一个目的是通过合理的边界划分以及演化机制来减少变更带来的影响。围绕业务功能进展组织根据康威定律“设计系统的组织其产生的设计等同于组

7、织之内、组织之间的沟通构造。微效劳更倾向于围绕业务功能对效劳构造进展划分、拆解。这样的效劳是针对业务领域有着关完好实现的软件它包含使用接口、持久存储、和对象的交互。因此团队应该是跨职能的包含完好的开发技术用户体验、数据库、和工程管理。产品moothing:antialiased;box-sizing:border-box;outline:0px;强化终端及弱化通道微效劳的应用致力松耦合以及高内聚所以更倾向于REST而不是复杂的协议如WS或BPEL或集中式框架或采用轻量级消息总线如RabbitMQ或者ZeroMQ等来发布消息。分散治理这是跟传统的集中式管理很大区别的地方。微效劳把单体式框架中的组

8、件拆分成不同的效劳在构建它们时将会有更多的选择。分散治理也意味着责任的下放每个团队对自己的业务效劳负责假如你维护一个7x24小时的不连续效劳那么你就必须24小时随时OnCall哪怕晚上3点起来处理问题就是AWS的形式。分散数据管理当单体式的应用使用单一逻辑数据库对数据持久化时企业通常选择在应用的范围内使用一个数据库。微效劳让每个效劳管理自己的数据库无论是一样数据库的不同实例或是不同的数据库系统。这一点我们后面会详细讲明。根底设施自动化云计算十分是AWS、Azure、Aliyun等的开展减少了构建、发布、运维微效劳的复杂性。微效劳的团队更加依赖于根底设施的自动化。其实不管是运维测试也是一样。容错

9、性设计任务效劳都可能因为供给商或底层硬件或者网络的不可靠而故障。微效劳应为每个应用的效劳及数据中心提供日常故障检测以及恢复采集各项系统状态指标以及业务指标、日志信息进展监控并提供预警报警才能。面向失败的设计后面也会再讨论。改良设计组件的关键特性是可替代性以及可晋级性由于设计会不断更改微效劳所提供的效劳应该可以交换或报废而不是要长久的开展的每种设计也一样都有自己的阶段使命以及生命周期。这样假如客户需要兼容性版本控制是一种好的手段。ChrisRichardson那么简化了这种讲法认为微效劳是一种架构风格通过一组效劳的方式构造系统同时需要知足如下条件高可维护性以及测试性松耦合性可独立部署围绕业务才能

10、进展组织一个小团队对其完全负责微效劳架构可以快速、频繁以及可靠地发布大型的复杂应用系统也可以使得组织可以进化出自己的技术栈。PeterLawyer讲微效劳很多地方十分像是MikeGancarz总结的Unix哲学小即是美Smallisbeautiful让程序只做好一件事Makeeachprogramdoonethingwell尽可能早地建立原型Buildaprototypeassoonaspossible可移植性比效率更重要Chooseportabilityoverefficiency尽可能地榨取软件的全部价值Usesoftwareleveragetoyouradvantage.微效劳架构就是U

11、nix哲学在分布式系统里的应用。微效劳架构的哲学本质上等于Unix哲学里的“让程序只做好一件事效劳都很小细粒度地执行单个功能。组织文化应拥抱自动化部署以及测试。这减轻了管理以及运维的负担。文化以及设计原那么应拥抱失败以及错误类似于抗脆弱系统。每个效劳都是弹性的回弹性的可组合的最小化的以及完好的弹性以及回弹性参见响应式微效劳。从这里我们可以得出一个结论一个微效劳架构的系统需要知足一系列的条件以及原那么而不仅仅是讲使用了某个微效劳的技术框架就是微效劳架构。微效劳这个词目前也过于流行以致于有些泛滥了。很多技术组件或框架例如可以用来暴露效劳可以用来自动化部署可以用来管理配置等等它们都可以用来作为微效劳

12、架构设计时的某个组成局部。但是单独用一个并不代表我们实现了微效劳设计而只能讲明我们借鉴了一些微效劳的思想。另一方面我们在做微效劳的时候也不用把市面上所有的微效劳组件都拿来用。就像是我们写个业务系统不会用到JDK的所有API画一幅画之前我们买了一盒24支的水彩笔实际上我们可能做一幅作品最终只用到了5-6个颜色的水彩笔。微效劳架构的特点、优势以及常见技术微效劳的四个特点以及六个才能如今让我们分析一下上一节里的各个技术大牛们阐述的技术观点从设计开发、系统部署、测试运维以及效劳治理四个主要方面来考虑微效劳架构的特点那么这四个方面就可以总结为下列图微效劳架构首先是一个分布式的架构其次我们要暴露以及提供业

13、务效劳才能然后我们需要考虑围绕这些业务才能的各种非功能性的才能。这些分散在各处的效劳本身需要被管理起来并且对效劳的调用方透明这样就有了效劳的注册发现的功能需求。同样地每个效劳可能部署了多台机器多个实例所以我们需要有路由以及寻址的才能做负载平衡提升系统的扩展才能。有了这么多对外提供的不同效劳接口我们一样需要有一种机制对他们进展统一的接入控制并把一些非业务的策略做到这个接入层比方权限相关的这就是效劳网关。同时我们发现随着业务的开展以及一些特定的运营活动比方秒杀大促流量会出现十倍以上的激增这时候我们就需要考虑系统容量效劳间的强弱依赖关系做效劳降级、熔断系统过载保护等措施。以上这些由于微效劳带来的复杂

14、性导致了应用配置、业务配置都被散落到各处所以分布式配置中心的需求也出现了。最后系统分散部署以后所有的调用都跨了进程我们还需要有能在线上做链路跟踪性能监控的一套技术来协助我们时刻解析系统内部的状态以及指标让我们可以随时对系统进展分析以及干预。这六种才能总结如下列图微效劳的优势这个图x轴是系统复杂度y轴是开发的消费力我们可以看到在系统复杂度很低的时候单体的消费力要高一点这是因为拆分微效劳管理这些效劳的本钱增加了当复杂度开场增加单体的消费力快速的降低而微效劳那么不太受影响这是因为复杂度大了单体牵一发而动全身各种耦合以及互相影响过多随着复杂度越来越高微效劳的低耦合开场减低了消费力的衰变而单体架构的消费

15、力那么会降到一个非常低的程度也就是讲微效劳应用在复杂度低的情况下t:none;-webkit-font-smoothing:antialiased;box-sizing:border-box;margin:0px0px1.1em;outline:0px;搞清楚了微效劳架构与单体架构的消费力的区别以后我们再来看看微效劳有哪些优势我总结了一下有以下几点效劳简单因为微小所以简单从一个大泥球变成了很多个小而美的颗粒每个小颗粒职责单一边界明确可以通过简单组装完成大的功能自然就比之前的大泥球好处理得多。灵敏扩展单体的情况下只能通过增加机器再部署多套单体系统做成集群前面加负载平衡来扩展微效劳以后我们会发现用

16、户效劳压力不大不用扩展订单效劳压力大的时候多部署两台就可以了这样我们就把扩展的方式从全部惯用户效劳的业务就可以上手工作了。独立演进变成微效劳以后各个独立系统的内部设计以及实现细节都被隔分开互相之间不受影响只要效劳间的接口不变大众就可以各自独立的开展自己的系统完成晋级、重构、功能增强等等。混合开发各效劳独立开发的另外一个好处就是各个独立系统可以使用自己的技术栈以及研发形式包括开发语言以及工具、数据库存储以及中间件等技术这样有助于试验以及引入更先进以及创新的技术从一些个边缘效劳开场尝试技术、工具、中间件、研发形式孵化成熟以后可以大范围推广实现技术以及研发才能的持续更新换代让研发组织保持长期的优势以

17、及活力充分获得技术开展的红利。持续交付微效劳比单体系统简单明确这样就便于我们利用自动化测试以及自动化部署来加速功能的迭代配合CI/CD等根底设施实现业务功能的持续交付保障研发可以紧跟业务开展变化的节奏。常见的微效劳技术框架详细怎么做微效劳呢我们先看看大众最常简单见到的微效劳的图在互联网出行业务中用户通过API网关访问系统的乘客、司机、出行三个REST效劳这三个效劳再通过REST访问计费、支付以及通知三个效劳。看起来很简单也好理解但是实际的业务系统里设计以及实现一般会是这样效劳框架我们可以选择用SpringCloud或ApacheDubbo包括新兴的SpringCloudAlibaba还有华为奉

18、献的ApacheServiceComb蚂蚁金服的SOFAStackOracle的HelidonRedhat的Quarkus基于Scala语言以及Akka的Lagom基于Grails语言的Micronaut基于Python语言的Nameko基于Golang语言的go-micro支持多语言混编的响应式微效劳框架Vert.X腾讯开源的Tars百度开源的ApacheBRPC孵化中微博的简化版Dubbo框架Motan等等。配置中心ApolloNacosdisconfSpringCloudConfig或Etcd、ZK、Redis自己封装效劳注册发现EurekaConsul或Etcd、ZK、Redis自己封

19、装效劳网关Zuul/Zuul2SpringCloudGatewaynginx系列的OpenResty以及Kong基于Golang的fagongziGateway等容错限流HystrixSentinelResilience4j或直接用Kong自带的插件消息处理Kafka、RabbitMQ、RocketMQ和Pulsar可以使用SpingMessaging或SpringCloudStream来简化处理SpingCloud与ApacheDubbo、SpringCloudAlibaba可以看到很多组件都是由Netflix奉献的。而ApacheDubbo定位是一款高性能、轻量级的开源JavaRPC框架它

20、提供了三大核心才能面向接口的远程方法调用智能容错以及负载平衡和效劳自动注册以及发现。所以我们可以看到Dubbo提供的才能只是SpringCloud的一局部子集。同时Dubbo工程重新维护以后捐献给了Apache工程的导师就是SpringCloud的核心人员。自这时候起Dubbo工程就开场在合适SpringCloud体系结果就是Alibaba也基于自己的一系列开源组件以及技术实现了SpringCloudAlibaba并顺利从SpringCloud孵化器毕业。详见SpringCloudAlibaba致力于提供微效劳开发的一站式解决方案。此工程包含开发分布式应用微效劳的必需组件方便开发者通过Spri

21、ngCloud编程模型轻松使用这些组件来开发分布式应用效劳。主要功能以及开源技术栈效劳限流降级Sentinel默认支持WebServlet、WebFlux,OpenFeign、RestTemplate、SpringCloudGateway,Zuul,Dubbo以及RocketMQ限流降级功能的接入可以在运行时通过控制台实时修改限流降级规那么还支持查看限流降级Metrics监控。效劳注册与发现Nacos适配SpringCloud效劳注册与发现标准默认集成了Ribbon的支持。分布式配置管理Nacos支持分布式系统中的外部化配置配置更改时自动刷新。消息驱动才能ApacheRocketMQ基于Spr

22、ingCloudStream为微效劳应用构建消息驱动才能。分布式事务Seata使用GlobalTransactional注解高效并且对业务零侵入地解决分布式事务问题。可以看到根本上功能都比拟完备了。第二局部微效劳最正确理论?管理的常识?一书里讲管理的核心是不断的解决推进工作经过中出现的各种问题。同样地我认为架构的核心那么是不断的解决系统设计实现与演化经过中的各种问题。FredBrooks在?人月神话?里讲“没有银弹如今仍然成立微效劳也并不是只有优点没有副作用把系统拆分了了很多局部每一个局部简单了但是整体的关系变复杂了。前面介绍了那么多微效劳的特点以及优势和相关技术我们再来分析一下微效劳存在的问

23、题进而讨论什么场景合适使用微效劳什么场景不合适和最正确的理论方式。微效劳架构首先是一个分布式系统架构。分布式系统的开展来历已久但是近年度来产生了理论以及实现的大爆发。究其原因分布式系统的开展得益于廉价pc硬件使得堆机器成为可能而单机的本钱/容量是非线性的所以分布式的核心是线性的程度扩展整个集群的功能和带来的协调机制管理复杂度数据以及状态一致性容错以及故障恢复容量与弹性伸缩这些通用性的根底才能建立。简单的翻译一下单个机器堆资源晋级CPU内存加大一倍想要增加一倍的处理才能且本钱不超过一倍不仅很难、而且不现实了。这样我们就需要考虑怎么通过进一步对于系统里不同功能的局部拆解开单独扩展这些能程度扩展的局

24、部进而在控制本钱的前提下提升整个系统的处理才能。另外我们如今都知道设计系统假如对可靠性可用性有非常高的要求那么需要先假设上下游都是不可靠的依赖的根底设施以及网络也是不可靠的这样就考虑分布式后的分片、复制、故障转移、灾难恢复等分布式系统下我们可以对系统的不同性质的节点、不同可靠性可用性要求的组件做针对性的单独处理。很多系统看起来是分布式的其实是一个大单机。很多系统看起来是微效劳的其实是一个大单体。就像人月神话里讲的往已经延期的工程加人手可能会导致更延期。问题不是出如今应不应该加人或应不应该使用分布式上。而是施行的人没搞清楚关键。比方系统拆成分布式或者微效劳然后某个关键地方仍然卡住了业务流程可能整

25、体还不如单机的扩展性失效多加机器还不如单机。同样的假如我们拆分了很多更小独立的效劳但是一个业务恳求进来还是在一些地方被卡住导致有一些瓶颈使得整个拆分后并不比之前有整体的改良那么其实是费力的做了一个大单体系统。所以合理的拆分微效劳使得我们可以更好的扩展系统是关键同时假如业务简单流量不大不扩展可以以很好的应对系统对于可用性以及一致性要求也不是十分高那么分布式以及微效劳也不是必须的。微效劳系统合适的场景以下几类系统比拟合适使用微效劳架构或使用微效劳架构改造大型的前后别离的复杂业务系统后端业务越复杂越需要我们合理的设计以及划分长期的维护本钱会非常高历史包袱也很重这个问题后面会详谈。变化开展十分快的创新

26、业务系统业务快就意味着天天要“拥抱变化每一块的业务研发都要被业务方压的喘不过气不做拆分、自动化一方面研发资源永远不够用活永远干不完另一方面不停的在给系统打补丁越来质量越低出错的可能性也越来越大。规划中的新大型业务系统假如有才能一开场就应该考虑做微效劳而不是先做单体还是开展到一定的阶段再做改造改造一定是伤筋动骨的大手术固然我们可以采取一些策略做得更平滑但是本钱还是比拟高的。敏捷自驱的小研发团队拥抱新技术可以直接用微效劳做系统不但的通过快速迭代、持续交付经过一定时间的尝试以及调整形成自己的微效劳理论经历这样在团队扩大时可以把好的经历复制到更大的团队。反过来以下几类系统不太合适一开场就做微效劳小团队

27、技术根底较薄弱创业初期或团队新做的快速原型这个时候做微效劳的收益明显比单体要低快速把原型做出来怎么方便怎么来用团队最熟悉的技术栈。流量不高压力小业务变化也不大单体能简单搞定的就可以先不考虑微效劳不考虑分布式因为分布式以及微效劳带来的好处可能还缺乏以抵消复杂性增加带来的本钱。对延迟很敏感的低延迟高并发系统低延迟的秘诀就是离io能多远就多远离cpu能多近就多近分布式以及微效劳导致增加了网络跳数延迟就没法降低。技术导向性的系统技术产品这类产品跟业务系统不同常规的业务系统研发方法不是太合适。微效劳带来的一些问题ChrisRichardson在提到了微效劳的几个缺乏效劳大小微效劳强调了效劳大小有人强调效

28、劳要大一点也有人愿意采用小效劳。需要注意这只是一种选择微效劳的目的是有效的拆分应用实现敏捷开发以及部署。进程通讯微效劳应用是分布式系统由此会带来分布式固有的复杂性。开发者需要在RPC或消息传递之间选择并完成进程间通讯机制。相对于单体式应用中通过语言层级的方法或进程调用微效劳下这种技术显得更复杂一些需要考虑RPC的超时、重试、失效策略或消息效劳不可用堆积堵塞等问题。数据库拆分数据库事务对于单体式应用来讲很容易因为只有一个数据库。在微效劳架构应用中需要更新不同效劳所使用的不同的数据库。使用分布式事务并不一定是好的选择不仅仅是因为CAP理论还因为很多中间件并不支持这一需求。最终你不得不使用一个最终一

29、致性的方法进而对开发者提出了更高的要求以及挑战。测试复杂度比方采用流行的SpringBoot架构对一个单体式web应用测试它的RESTAPI是很容易的事情。反过来同样的一个业务场景需要测试启动以及它有关的所有效劳这些效劳在不同的进程所以变得尤为复杂。效劳依赖关系微效劳架构形式应用的改变将会涉及多个效劳。比方假设你在完成一个案例需要修改效劳A、B、C而A依赖BB依赖C。在单体式应用中你只需要改变相关模块整合变化部署就好了。比照之下微效劳架构形式就需要考虑相关改变对不同效劳的影响。比方你需要更新效劳C然后是B最后才是A幸运的是许多改变一般只影响一个效劳而需要协调多效劳的改变很少。十分是假如要处理的

30、效劳间依赖是一个网状关系那么很可能导致我们修改A时考虑到了会影响BCDEF这几个效劳但是漏掉了影响系统K导致上线以后发现K的局部功能无法使用了。部署复杂度部署一个微效劳应用也很复杂一个分布式应用只需要简单在负载平衡效劳后面部署各自的效劳器就好了。每个应用实例是需要配置诸如数据库以及消息中间件等根底效劳。而一个微效劳应用一般由大批效劳构成。例如根据AdrianCockcroftHailo有160个不同效劳构成NetFlix有大约600个效劳。每个效劳都有多个实例。这就造成许多需要配置、部署、扩展以及监控的局部除此之外你还需要完成一个效劳发现机制以用来发现与它通讯效劳的地址包括效劳器地址以及端口。

31、传统的解决问题方法不能用于解决这么复杂的问题。接续而来成功部署一个微效劳应用需要开发者有足够的成熟部署方法并高度自动化。PeterLawyer有在中提出微效劳的几个问题效劳形成信息障碍。引入了额外的复杂性以及新问题例如网络等待时间消息格式负载平衡以及容错。忽略其中之一属于“分布式计算的错误。测试以及部署更加复杂。整体应用程序的复杂性仅转移到网络中但仍然存在。细粒度的微效劳已被批评为一种反形式。怎样合理拆分微效劳粒度怎样控制对业务按粒度以及边界拆解的问题这决定了我们的效劳是不是合理开发以及维护是不是方便。核心思路是深化解析业务。遗留系统应该怎样改造从哪儿下手怎样推动改造遗留系统一般来讲比重新做一

32、个新系统更复杂怎样平滑的、最大代价的将老系统改造成微效劳也是一个宏大挑战。拆分后的性能应该怎样保障性能有两个指标关键是区分出来怎样处理不同特性的数据关注不同的指标做好优化以及选型针对详细细节详细对待。怎么考虑拆分后的数据一致性分布式事务的选取以及取舍多个效劳间的业务数据一致性的问题事务是个需要重点考虑的问题主要是考虑强一致性的分布式事务还是可以使用最终一致的弱一致性。对于一般的业务可能使用补偿冲正类的做法在业务允许的一定时间内数据到达一致状态即可比方30s或10分钟。系统以及效劳的高可用可伸缩怎样实现高可用意味着系统稳定强健可伸缩意味着弹性资源有效使用怎样做到无状态、不分享是实现可高用可伸缩的

33、关键。拆分经过的测试以及部署怎样处理怎么提升管理才能降低风险跨系统的协作问题、测试的问题这对于技术才能以及研发成熟度较低的团队会带来很大费事。核心思路定义好业务边界、系统间接口与数据标准提升自动化测试程度。微效劳架构由于拆分粒度较细测试是个大问题。在保持每块职责单一的同时关键是保证接口稳定做好自动化测试十分是UT以及接口的自动化以及持续集成尽量少全流程的人工回归测试。部署单元过多导致维护本钱上升的问题要管理的点多了问题自然复杂了核心思路是自动化部署与运维。拆分后的运维以及监控怎样处理怎么应对系统的故障关键是保障核心技术的指标和业务指标做好预警报警积累问题、寻找根因控制以及杜绝低级失误。七个关键

34、问题的应对策略怎样合理拆分微效劳当一个系统效劳化的时候就会面临一个问题怎样进展效劳的划分怎么确定效劳的粒度有没有一些可以参考的业界通用规那么实际上效劳划分的本质是对系统进展架构设计效劳的划分粒度没有绝对的过大或者过小之讲不同阶段的侧重点以及考虑的角度也不尽一样。创业初期的团队过分的追求微效劳为了“微而微反而会导致业务逻辑过于分散技术架构过于复杂团队根底设施搭建才能弱进而导致忽略了快速迭代交付产品的重要性可能错失了市场时机。所以关于效劳的划分不是对错的选择题而是需要综合考虑各种外界的因素所作出的一个最合适的决策这些外界因素通常包括业务、技术债、开发、运维、测试这五个方面业务所处领域的市场性质对市

35、场比拟敏感的工程创业初期粒度应该尽量划分的粗一些先提供充足的弹药去占领市场然后再去考虑对系统进展重构以及优化与原有系统之间的关系对于历史遗留的系统需要做好新旧系统之间的边界划分防止过于激进、过大幅度的改造应该采取小步快跑的方式有节奏的对老系统进展效劳化改造开发团队的成熟度效劳化带来的技术风险应该提早进展评估要考虑团队的承受度用适宜的人做合适的事考虑团队需要有包括敏捷包括Devops包括根底设施运维以及测试的自动化等根底才能根底设施的搭建才能在进展细粒度的效劳划分时要考虑团队是否有足够的才能来支撑大量效劳实例运行的运维复杂度是否可以做好分布式的日志追踪以及效劳的监控测试团队的测试执行效率过于细粒

36、度的效劳划分假如测试团队不能通过自动化测试、自动回归、压力测试、极限测试等手段来进步测试执行效率必然会带来测试工作量的大幅度上升进而影响整个工程的上线周期假如没有十分强烈的大规模程度扩展需求拆分就没有必要反而把问题搞复杂了。进展效劳化的拆分时通常会先按照业务子系统先进展一次划分根据业务逻辑以及数据的关系划分为假设干个子系统然后再考虑子系统内部是否可以再次进展拆分。至于拆分的根本原那么我推荐高内聚低耦合这个已经提了很多了简单讲一下就是要把强相关的局部总是会一起改动的局部聚合到一起相关性不大的局部拆开可以参考DDD中的一些方法。粗粒度效劳效劳的粒度要略微的抽象以及粗粒度一些因为效劳是基于业务场景的

37、抽象以及设计不能做成是直接把数据库的增删改查暴露出来成接口以及方法而是应该隐藏这些细节考虑清楚从业务以及客户角度来看哪些步骤以及经过是必须封装起来的细节隐藏掉然后对外提供的就是粗粒度的效劳而在单体系统的时候我们可以直接调用这些细节无需太多考虑。1拆分之前先梳理系统关系以及接口其中准备阶段主要是梳理清楚了依赖关系以及接口就可以考虑怎样来拆第一刀切在哪儿里即能到达快速把一个复杂单体系统变成两个更小系统的目的又能对系统的现有业务影响最小。要尽量防止构建出一个分布式的单体应用一个包含了一大堆相互之间紧耦合的效劳却又必须部署在一起的所谓分布式系统。没分析清楚就强行拆可能就一不小心剪断了大动脉立马搞出来一

38、个A类大故障后患无穷。2不同阶段拆分要点不同每个阶段的关注点要聚焦拆分本身可以分成三个阶段核心业务以及非业务局部的拆分、核心业务的调整设计、核心业务内部的拆分。这三个阶段第一阶段将核心业务瘦身把非核心的局部切开减少需要处理的系统大小第二阶段。重新按照微效劳设计核心业务局部第三阶段把核心业务局部重构设计落地。拆分的方式也有三个代码拆分、部署拆分、数据拆分。代码直接表达了依赖关系拆完就可以单独打包部署。但是有时候我们可以通过控制一些提供效劳的开关使用同一份代码以及打包的程序部署多组进程每组提供不同的效劳这就是部署拆分比方同一份代码我们部署了3组机器A组5台提供订单效劳B组2台提供用户效劳C组2台提

39、供任务调度处理任务。数据拆分最复杂涉及到代码的调整SQL以及事务的分析以及重构数据库表的拆分甚至数据迁移数据构造的调整以及数据迁移那么一般意味着需要停机维护。这三个方式可以在适当的条件下选择先做哪个操作适宜。另外每个阶段需要聚焦到一两个详细的目的否那么目的过多反而很难把一件事儿做通透。例如某个系统的微效劳拆分制定了如下的几个目的性能指标吞吐以及延迟核心交易吞吐提升一倍以上TPS1000-10000A业务延迟降低一半Latency250ms-125msB业务延迟降低一半Latency70ms-35ms。稳定性指标可用性故障恢复时间可用性99.99%A类故障恢复时间15分钟季度次数1次。质量指标编

40、写完善的产品需求文档、设计文档、部署运维文档核心交易局部代码90%以上单测覆盖率以及100%的自动化测试用例以及场景覆盖实现可持续的性能测试基准环境以及长期持续性能优化机制。可维护性指标建立全面完善的监控指标、十分是全链路的实时性能指标数据覆盖所有关键业务以及状态缩短监控报警响应处置时间配合运维团队实现容量规划以及管理出现问题时可以在一分钟内拉起系统或回滚到上一个可用版本启动时间1分钟。易用性指标通过重构实现新的API接口既合理又简单极大的知足各个层面用户的使用以及需要客户满意度持续上升。业务支持指标对于新的业务需求功能开发在保障质量的前提下开发效率提升一倍开发资源以及周期降低一半。核心人员指

41、标培养10名以上熟悉核心交易业务以及新系统的一线技术人员形成构造合理的核心研发人才梯队。结果可想而知了目前过多了反而没有目的。最后第一阶段只选择了稳定性作为最重要的指标先稳住系统然后再在后面的阶段里选择其他指标逐步实现各个目的。3快速迭代找到打破口持续产出4大胆假设小心求证稳步上线凡事不破不立拆分改造经过我们每一次改动的地方可能有多个不同的方案以及途径详细选择哪一个最适宜这需要我们放开思路大胆假设充分吸收各方面的意见以及想法然后小心慎重的去测试甚至在线上做验证保障万无一失后最后上线。5保障质量不断重构以及改善现有设计以及代码所有的事物都有产生开展衰退以及消亡的经过。长期来看软件系统的代码质量肯

42、定是会一直下降的就像是人的身体安康到了一定的程度就会难以为继需要重构或重做。而不断的重构改善现有的设计集合代码就像是一直在保养身体可以减缓衰老保证安康增加寿命。6获得指导以及业务方的支持经过以及决策透明化拆分改造看起来没有给系统带来明确的可见收益比方没有明显改良了用户体验也没有给系统新增了一个业务功能但是却涉及到多方介入付出劳动这就必然会带来很大的阻力怎么办呢还是从?管理的常识?一书里我看到了一个很有道理的话假如无法推动问题背后的人解决问题那讲明对问题挖掘的还不够深“。当代化的工作教会我们双赢/多赢是协作的唯一方法也是可以持续的方法。搞清楚怎么才能推动各个合作方的支持怎么才能让指导同意假如我们

43、如今提的意见他们不同意那么他们关心的点是什么怎么把他们关心的点纳入到这个工作范围里来进而实现大众可以达成一致来合作。同时需要注意的是信息一定要透明决策要公开让大众都直接介入到这个经过进而明确目的一致前行。总结成48字箴言的“微效劳拆分核心价值观功能剥离、数据解耦自然演进、逐步拆分小步快跑、快速迭代灰度发布、慎重试错提质量线、还技术债各方一致经过透明理想中的系统拆分改造效果实际上一般最后都鸡飞狗跳关于微效劳对性能的影响大众可以先考虑2个问题延迟latency以及吞吐量throughout有什么关系延迟是响应时间么先讲一下延迟以及响应时间延迟是对于效劳本身来讲的响应时间是相当于调用者来讲的更多的内

44、容可以参考?数据密集型应用系统设计?一书延迟latency恳求响应出入系统的时间响应时间ResponseTime客户端恳求开场一直到收到响应的时间延迟网络耗时理想状态下延迟越低吞吐越高当然这是对单机单线程而言的在分布式下就不成立了举个反例比方从密云水库拉一个水管到国贸水流到国贸需要1小时假如再拉一个水管到顺义20分钟就可以。假如你在国贸用水龙头接水你可以单位时间接到非常多的水这个数量跟你在过国贸还是顺义没有关系只跟水库单位时间输入的水量/水压有关系。但是假如你在水管里放一个小球它从密云到国贸的时间是到顺义的时间的三倍这样对于到国贸的这个水管系统延迟很高但是系统的吞吐量跟到顺义的是一样的。同理假

45、如一个单体系统被拆分成了10个效劳假设一个业务处理流程要经过5个效劳这5个效劳只要是每个吞吐量TPS/QPS不低于原先的单体那么整个微效劳系统的吞吐量是不变的。相反地我们通过效劳变小关系变简单数据库简化事务变小等等假如5个系统的吞吐都比原来的系统打那么改造后的系统整体的吞吐也比之前要高。那么这个经过的副作用是什么呢简单的讲就是延迟变高了原来都是本地调用如今变成了5次远程调用假设每次调用的网络延迟在1-10毫秒物理机房万兆网卡可以很低云环境下比拟高那么延迟就会比之前增加增加5-50毫秒而且前提是分布式下的恳求使用异步非阻塞的流式或者消息处理方式同步阻塞会更高而且影响吞吐量。好在低延迟的系统要求比

46、拟少见对于一般的业务系统来讲可以程度扩展的才能比延迟增加几毫秒要重要的多。比方我们在淘宝或京东买个衣服交易步骤的处理在秒级都是可以承受的假如是机票、酒店、电影票之类的分钟级以上都是可以承受的。对于分布式微效劳系统的低延迟设计更多信息可以参考PeterLawyer的boke。怎么考虑拆分后的数据一致性微效劳提倡每一个效劳都使用自己的数据库存储这就涉及到老系统的数据库拆分改造。一般的数据库拆分我们可以把不同业务效劳涉及的表拆分到不同的库中去这样假如之前的事务中操作的两个表假如被拆分到了不同的数据库就会涉及到分布式事务。下面先解释一下分布式事务。我们知道ACID原子性Atomicity、一致性Con

47、sistency、隔离性Isolation、持久性Durability定义了单个数据库操作的事务性这样我们就能放心的使用数据库而不用担忧数据的一致性操作的原子性等等。由于数据库同时可以并发的给多个应用、多个会话线程使用这样就涉及到了锁隔离级别以及数据可见性等一系列工作好在关系数据库都已经帮我们解决了这些问题。但是在SOA、分布式效劳化以及微效劳架构的大背景下数据拆分到多个不同的库已经是常态这种改造或设计中同一个业务处理涉及到的关联数据生命周期可能要贯穿到多个不同的数据库假如没有事务保证那么数据的一致性或正确性就会收到破坏账就可能会错乱了平台或客户就会产生损失了。怎样保证数据的事务性那么是一个非

48、常有意思的话题。传统的数据库以及消息系统一般都是支持XA分布式事务通过一个TM事务管理器协调各个RM资管管理器每个RM管理自己的本地事务通过两阶段提交2PC来保障一致。由于CAP的不可能三角约束下我们大局部时候选择了从ACID到BASEBasicallyAvailable根本可用,Soft-state柔性状态,Eventuallyconsistent最终一致这样分布式事务我们一般也从XA变成了TCCTry-Commit-Cancel把分布式事务的控制权从底层资源层比方数据库挪到了业务实现层进而通过释放数据库层的锁来提升性能以及灵敏性。详细情况可以参阅下面的两个文章。分布式事务的原理综述讲的非常

49、详细PKHckm6uZ3TgJYfRnw分布式事务解决方案与适用场景分析结合实际详细讲明了TCC的原理以及用法我的好朋友长源以及张亮也分别写过一个分布式事务的系列长源-漫谈分布式事务s:/zhuanlan.zhihu/distributedDatabase张亮-分布式事务假如直接操作数据库或支持XA/JTA的MQ可以使用XA事务。其他情况可以使用开源的分布式事务中间件。开源的分布式事务中间件有ApacheServiceCombPackSeata/FescarApacheShardingSphere等。但是实际上对大局部业务来讲性能远大于分布式事务带来的强一致性要求。更多时候我们可以先牺牲掉强一致性甚至是准实时一致性先让多个不同节点的效劳都自己单独把业务执行掉。然后再通过定时任务去检查是否一致的状态假如不一致保证可以从某个存储拿到原来的数据重新执行即可。这时候其实是做了补偿的操作补偿会带来