面向服务与微服务架构.docx

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

1、面向服务与微服务架构文中主要描绘以及讨论了最近流行起来的一种效劳架构形式微效劳以及我最近几年度工作的理论比拟相关感觉深受启发。本文吸收了局部原文观点结合自身理论经历来讨论下效劳架构形式的演化。面向效劳架构SOA面向效劳架构SOA思想概念的提出已不是什么新颖事大概在10年度前就有不少相关书籍介绍过。当时java企业应用领域J2EE仍然是主流应用程序被部署在庞大统一的符合J2EE标准的容器中运行在单一进程中提供所有的功能。而SOA提出的一些架构原那么在当时看来无疑是革命性的。由于业已存在的大量单一庞大的应用按照SOA的思想以及架构原那么来改造无疑相当于推翻重新开发一遍在本钱上很难承受。因此早期的S

2、OA通常以及另外一个术语关联在一起ESB企业效劳总线。当时在SOA的施行思路上无一例外的选择了ESB形式来整合集成大量单一庞大的应用以保护企业前期投入本钱。因此ESB其实是SOA特定历史阶段的一种实现方式。然而愿望总是美妙的现实却要残酷的多。过去这些年度我们看到了很多施行ESB搞砸了的工程投入几百万产出几乎为0因此SOA这个概念也蒙上了不详的标签。近几年度流行起来的效劳化架构其拥护者开场回绝使用包裹着失败阴影的SOA这个标签而称其为微效劳架构MicroservicesArchitectureStyle。但事实上微效劳架构仍然是SOA架构思想的一种实现。微效劳架构Microservices对微效

3、劳架构我们没有一个明确的定义但简单来讲微效劳架构是采用一组效劳的方式来构建一个应用效劳独立部署在不同的进程中不同效劳通过一些轻量级交互机制来通信例如RPC、HTTP等效劳可独立扩展伸缩每个效劳定义了明确的边界不同的效劳甚至可以采用不同的编程语言来实现由独立的团队来维护。微效劳架构特征Characteristics1.通过效劳实现组件化传统实现组件的方式是通过库library传统组件是以及应用一起运行在进程中组件的部分变化意味着整个应用的重新部署。通过效劳来实现组件意味着将应用拆散为一系列的效劳运行在不同的进程中那么单一效劳的部分变化只需重新部署对应的效劳进程。另外将效劳作为组件可以更明确的定义

4、出组件的边界因为效劳之间的调用是跨进程的明晰的边界以及职责定义是设计时必须考虑的。2.按业务才能来划分效劳与组织团队指出organizationswhichdesignsystems.areconstrainedtoproducedesignswhicharecopiesofthecommunicationstructuresoftheseorganizations.任何设计系统的组织最终产生的设计等同于组织之内、之间的沟通构造。传统开发方式中我们将工程师按技能专长分层为前端层、中间层、数据层前端对应的角色为UI、页面构建师等中间层对应的角色为效劳端业务开发工程师数据层对应着DBA等角色。事实

5、上传统应用设计架构的分层构造正反响了不同角色的沟通构造。而微效劳架构的开发形式不同于传统方式它将应用按业务才能来划分为不同的效劳每个效劳都要求在对应业务领域的全栈从前端到后端软件实现从界面到数据存储到外部沟通协作等等。因此团队的组织是跨功能的包含实现业务所需的全面的技能。近年度兴起的全栈工程师正是因为架构以及开发形式的转变而出现当然具备全栈的工程师其实很少但将不同领域的工程师组织为一个全栈的团队就容易的多。3.效劳即产品传统的应用开发都是基于工程形式的开发团队根据一堆功能列表开发出一个软件应用并交付给客户后该软件应用就进入维护形式由另一个维护团队负责开发团队的职责完毕。而微效劳架构的倡导者提议

6、防止采用这种工程形式更倾向于让开发团队负责整个产品的全部生命周期。Amazon对此提出了一个观点Youbuidlit,yourunit.开发团队对软件在消费环境的运行负全部责任让效劳的开发者与效劳的使用者客户形成每天的沟通反应来自直接客户端的反应有助于开发者提升效劳的质量。4.智能终端与哑管道微效劳架构抛弃了ESB过度复杂的业务规那么编排、消息路由等。效劳作为智能终端所有的业务智能逻辑在效劳内部处理而效劳间的通信尽可能的轻量化不添加任何额外的业务规那么。5.去中心统一化传统应用中倾向采用统一的技术平台或者产品来解决所有问题。不是每个问题都是钉子也不是每个解决方案都是一个锤子。问题有其详细性解决

7、方案也应有其针对性。用最合适的技术方案去解决详细的问题在大一统的传统应用中其实很难做到而微效劳的架构意味着你可以针对不同的业务效劳特征选择不同的技术平台或者产品有针对性的解决详细的业务问题。6.根底设施自动化单一进程的传统应用被拆分为一系列的多进程效劳后意味着开发、调试、测试、集成、监控以及发布的复杂度都会相应增大。必需要有适宜的自动化根底设施来支持微效劳架构形式否那么开发、运维本钱将大大增加。7.Designforfailure正因为将效劳独立在不同的进程中后引入了额外的失败因素。任何时刻对效劳的调用都可能因为效劳方不可用导致失败这就要求效劳的消费方需要优雅的处理此类错误。这其实是相对传统应

8、用开发方式的一个缺点不过随着一些开源效劳化框架的出现对业务开发人员而言适当的屏蔽了类似的错误处理不过开发人员仍然需要知道对效劳的调用是完全不同于进程内的方法或者函数调用的。8.进化设计一旦采用了微效劳架构形式那么在效劳需要变更时我们要十分小心效劳提供者的变更可能引发效劳消费者的兼容性破坏时刻谨记保持效劳契约接口的兼容性。对于解耦效劳消费方以及效劳提供方十分适用Beconservativeinwhatyousend,beliberalinwhatyouaccept.发送时要保守接收时要开放。按照伯斯塔尔法那么的思想来设计实现效劳调用时发送的数据要更保守意味着最小化的传送必要的信息接收时更开放意味

9、着要最大限度的容忍信息的兼容性。多余的信息不认识可以忽略而不应该回绝或者抛出错误。微效劳架构应用采用微效劳架构面临的第一个问题就是怎样将一个单一应用拆分为多个效劳。有一个一般的原那么是单一效劳提供的功能是可以独立被交换以及晋级的。也就是讲假如有A以及B两个功能假如A功能发生变化时同时B功能也需要变化那么A以及B这两个功能应该被划在一个效劳中。微效劳架构应用的成功经历近年度已越来越多例如国外的AmazonNetflix国内如阿里都采用微效劳架构获得了很多正面的成功案例。但通过上文所述微效劳架构特征看出其实微效劳架构形式有利有弊需要根据实际的业务、团队、环境进展仔细权衡利弊。其中的效劳拆分带来的额

10、外开发、测试、运维、监控的复杂度在现有的环境、团队下是否可以很好的支持。另外有人可能会讲我一开场不采用微效劳架构方式而是在单一进程内基于明晰定义的模块化方式模块之间通过接口调用到了适当阶段必要的时候再将模块拆分为效劳。其实这个想法显得过于理想因为进程内良好定义的接口通常不是很好的效劳化接口。一开场没有考虑效劳化的设计方法那么后期拆分时仍然是一个痛苦的经过。正如MartinFowler在其文中所讲微效劳架构是否就是企业应用开发的将来还有待时间的检验。就目前的情况看对此我们可以保持慎重的乐观这条路仍然值得去探究。实际任何的架构决策都是基于我们不完美的现状做出的这正是架构取舍的微妙之处超越任何的方法论。