《微服务架构平台构建指南》由会员分享，可在线阅读，更多相关《微服务架构平台构建指南（23页珍藏版）》请在金锄头文库上搜索。
1、微效劳架构平台构建指南如何从 0 构建起一个亿级恳求微效劳架构23目 录一微效劳实施的前置条件3二微效劳实施的具体步骤6三效劳拆分理论和原理及方法9四架构“三板斧”如何切入到微效劳框架中15五微效劳后效劳的测试方法25六线上监控的实现36七微效劳实施总结38如何从0 开头构建一个亿级恳求的系统历程，其中包括了效劳拆分、微效劳测试、容量预估以及上线等流程。稳定的系统不仅要依靠好的架构设计，而且需要对核心代码、高频访问模块精雕细琢。看似不起眼的一些小优化，长期积存起来就会有质的变化。正所谓细节打算成败，做架构也是同样的道理。一 微效劳实施的前置条件很多技术人员在听到企业技术架构要转型，打算从单体架
2、构往微效劳架构转型，得知消息后就特别的兴奋，认为自己马上又能学到新的技术了，开头去关注到底是选型哪种技术架构，并运行框架供给的Demo ，认为成功运行Demo 就具备了实施微效劳的条件了， 等待公司一声令下，就踏上微效劳之旅了。其实这是一种典型的技术人员考虑事情的思维，通过过往的阅历来看，更重要的是在实施微效劳之前全员统一思想、充分培训、以及工程构造标准化。统一思想：由于在预备实施微效劳的时候，首要条件就是获得高层的认可，由于涉及到组织构造的调整以及后续人力资源的增补，另外在新架构上线后难免会消灭问题，这个时候需要得到高层的支持。另外，在单体应用中其组织机构包括开发部、测试部、运维部、DBA
3、部，每个部门各司其职由高层统一指挥，看似很格外合理的组织构造，但是在工程或者迭代实际过程中会花费大量的时间去跨部门沟通，形成了孤岛式功能团队。充分培训：微效劳架构的开发人员具备“精”、“气”、“神”的特质，否那么在后续进展阶段肯定会消灭各种难题。“精”是指生疏业务，生疏选型的开发框架，而不仅限完成demo 运行，必需要生疏原理，最好能生疏源码，做到面对问题不慌，“气”是指大家对微效劳架构这件事情的思想认知全都，能够在一个频道上对话，“神”是指需要了解其理论学问，比方什么是效劳治理，什么是效劳自治原那么，明白为什么需要这样而不是那样。工程构造标准化：全部效劳交付效劳，从代码风格比方类的命名，mo
4、dule命名以及启动方式都是全都的，削减研发人员对于未知的未知而产生的担忧。在正式开头微效劳之前， 有必要了解下云原生的12 要素，它针对微效劳的一些设计思想做了充分的归纳和总结，云原生12 要素的内容如下：基准代码：一份基准代码Codebase ，多份部署 deploy 依靠：显式声明依靠关系配置：在环境中存储配置后端效劳：把后端效劳(backing services)当作附加资源构建、公布、运行：严格分别构建和运行进程：以一个或多个无状态进程运行应用端口绑定：通过端口绑定(Port binding)来供给效劳并发：通过进程模型进展扩展易处理快速启动和优雅终止可最大化强健性环境等价：开发环境
5、与线上环境等价日志治理进程其中第一条需要特别留意， 它要求基准代码或者软件制品只允许有一份，可以部署到多个环境，不由于环境的转变而需要重新编译或者针对不同的环境编译多个制品。记住，测试即交付的原那么，即你测试的软件制品和交付到生产的软件制品是一样的。重点强调环境配置和制品库分别，假设是测试环境的配置，那么软件运行起来就是测试环境，假设是生产环境的配置，那么软件运行起来就是生产环境。 觉察很多程序员都宠爱把配置文件写到工程里面，例如application-行失败。总结为三条：切实需要使用微效劳来解决实际问题；组织构造思想认知全都；前期有完善系统性针对微效劳的培训。dev.properties 、
6、application-test.properties、application-prod.properties等，然后在系统启动的时候增加spring.profiles.active=dev来说明环境，其实这种做法是格外的不优雅，首先违反了云原生12 要素第一个条件， 其次测试环境、 生成环境的全部的配置信息都暴露在代码中，简洁导致信息泄露，最终增加运维部署难度，一旦环境变量标识错误就会导致软件运二 微效劳实施的具体步骤有些人认为使用Dubbo或者SpringCloud把系统内部接口调用换成RPC 或者Rest 调用，就完成了微效劳改造了，其实这是只是微效劳的冰山一角，完整的去实施微效劳必需从
7、全局考虑统一规划，包括前后端分别，效劳无状态、统一认证以及运维体系的调整等。前后端分别 ：是指前端和后端的代码分别，前端负责HTML 页面的编写以及规律跳转，后端负责供给数据接口给前端，前后端开发人员可以并行开发。前端对跳转规律和UI 交互负责，后端对接口的高可用负责。 前端 html 层使用VUE 框架，node.js可以起到规律跳转的把握，前后端通信承受rest 方式， json 数据格式通信。前后端分别后的好处总结来说包含如下：各端的专家来对各自的领域进展优化，以满足用户体验优化效果最优化；前后端交互界面更加清楚，承受接口方式通信，后端的接口简洁明白，更简洁维护；前端多渠道集成场景更简洁
8、扩展，承受统一的数据和模型，可以支撑前端的web UI移动 App 等访问，后端效劳不需要改动；效劳无状态 ：是指该效劳运行的实例不会在本地存执行有状态的存储，例如不存储需要长久化的数据，不存储业务上下文信息，并且多个副本对于同一个恳求响应的结果是完全全都的，一般业务规律处理都被会定义为无状态效劳。记得在微效劳重构的初级阶段发生过一次特别有代表性的线上故障，有个研发人员负责验证码登陆模块开发，把验证码存入了本地缓存中，由于我们开发、测试环境都是单实例部署，所以并没有觉察问题，当线上是多实例部署，所以会导致大量用户登陆失败的场景。这个线上故障的核心问题点在于没有清楚的生疏无状态效劳和有状态效劳的
9、的使用场景。统一认证 ：统一认证与授权是开头实施效劳化的最根底条件，也是最根底的一项应用。在过去的单体应用中，可以基于拦截器和Session实现根本的登录与鉴权。在微效劳架构中，效劳都被设计为无状态模式，明显拦截器和Session模式已经不符合架构要求了，需要由统一认证效劳来完成认证鉴权以及和第三方联合登陆的要求，我们使用token机制来做统一认证， 主要流程如下：完成前后端分别， 效劳无状态改造、 统一认证处理后，根本上完成了微效劳轮廓的改造。接下来就需要去识别单体应用最需要改造成微效劳的模块，推举是一个模块甚至一个接口这样的进度去拆分单体应用，而不建议一次性全部重构完毕。用户输入用户名和密
10、码提交给认证效劳鉴权；认证效劳验证通过后生成token存入分布式存储；把生成的token返回给调用方；调用方每次恳求中携带token ，业务系统拿到token恳求认证效劳；认证效劳通过后业务系统处理业务规律并返回最终结果。三 效劳拆分理论和原理及方法谈到微效劳，谈论的最多，吵架的最多的就是效劳拆分问题，效劳拆分是否合理直接影响到微效劳架构的简单性、稳定性以及可扩展性。然而并没有任何一本书籍或者标准来介绍如何拆分效劳，那么如何正确的做效劳的拆分? 目前各家做法也都是依据架构师阅历以及业务形态和用户规模等因素综合考虑。在工作中曾经遇到以下二种效劳拆分的模式：一个方法一个效劳：视业务规模和业务场景而
11、定；基于代码行数的划分：简洁粗暴，不推举；有人说按方法拆分效劳太过于细致， 应当要按业务功能来拆。 其实当业务到达肯定规模的时候，按方法拆分是一种格外有效的做法，以用户效劳举例，在初始阶段的时候，用户效劳具备了用户的增删改查功能，当用户规模上升之后需要对增删改查功能做优先级划分。大家都知道在互联网中流量获客是最贵的，运营团队通过互联网投放广告获客，用户在广告页上填写手机号码执行注册过程，假设此时注册失败或者注册过程响应时间过长，那么这个客户就可能流失了，但是广告的点击费用产生了， 无形中形成了资源的铺张。 所以此时需要按方法维度来拆分效劳，把用户效劳拆分为用户注册效劳只有注册功能，用户根底效劳
12、修改、查询用户信息。在做效劳拆分的时候，每个效劳的团队人数规模也是格外重要的，人数过多可能会变成单体应用，沟通决策会缓慢，人数太少工作效率又会降低，一般来说会遵循2 个披萨原那么和康威定律：2 个披萨原那么： 两个披萨原那么最早是由亚马逊CEO 贝索斯提出的， 他认为假设两个披萨缺乏以喂饱一个工程团队，那么这个团队可能就显得太大了，所以一个效劳的人数划关于效劳拆分模式，使用比较多的是业务功能分解模式和数据库模式，由于简洁理解而且使用起来比较简洁，效果也很好。分为 5-7 人比较适宜。由于人数过多的工程将不利于决策的形成，而让一个小团队在一起做工程、开会争辩，那么更有利于达成共识，并能够有效促进
13、企业内部的创新。康威定律：你想要架构成为什么样， 就将团队分成怎样的构造。 比方前后端分别的团队，架构就是基于前后端分别。在基于微效劳设计的团队里，一个很好的理念是自治理，团队内部对于自己所负责的模块高度负责，进展端对端的开发以及运维。整个单体应用有那么多的功能，到底哪些业务功能需要拆分，哪些业务功能又不需要拆分呢？可以遵循效劳拆分的方法论：当一块业务不依靠或极少依靠其它效劳，有独立的业务语义，为超过 2 个或以上的其他效劳或客户端供给数据，应当被拆分成一个独立的效劳模，而且拆分的效劳要具备高内聚低耦合。业务功能分解模式：推断一个效劳拆分的好坏，就看微效劳拆分完成后是否具备效劳的自治原那么，假
14、设把简单单体应用改造成一个一个松耦合式微效劳，那么依据业务功能进展分解是最简单的，只需把业务功能相像的模块聚拢在一起。比方：用户治理：治理用户相关的信息，例如注册、修改、注销或查询、统计等。商品治理：治理商品的相关信息。数据库模式：在微效劳架构中，每个效劳安排一套单独的数据库是格外抱负方案，这样就缓解了单个数据库的压力，也不会由于某个数据库的问题而导致整个系统消灭问题。微效劳初始阶段效劳拆分不需要太细，等到业务进展起来后可以再依据子域方式来拆分，把独立的效劳再拆分成更小的效劳， 最终到接口级别效劳。 假设效劳拆分的过小会导致调用链过长，以及引发没有必要的分布式事务，此时阶段性的合并格外重要。做为架构师不仅要学会拆分服务，也需要学会合并效劳，需要周期性的去把拆分过小或者拆分不合理的效劳要准时合并。总得来说，在效劳拆分的时候需要抓住以下重点：高内聚的拆分模式以业务为模块拆分以迭代频率和改动范围拆分阶段性合并定期复盘总结代码构造如何做到提高研发效率曾经有一项调查，当一个程序员到新公司或者接手工程最怕的事情是什么，超过
