首先微服务粒度的划分要求工程师充分理解和洞察业务领域的边界保证你所拆分的服务是自包含的。所谓“自包含”就是说你的服务是可以独立部署、独立演进的你的服务可以自主地完成某个特定的、单一的功能。
其次细粒度服务应该同时具备高内聚和低耦合两个特征。高内聚要求将系统中相关的元素和行为聚集在一起把不相关的元素和行为放在别处低耦合是指降低微服务之间的相互依赖程度和相互作用关系如果服务之间存在紧密联系说明它们的耦合度比较高最好不要做拆分操作而应该做聚合操作这样可以使信息的传递和协作比拆分成独立的服务更加简单可控。
另外细粒度服务应该尽量做到独立。这一特性也适用于单一职责 原 则 SRP Single Responsibility Principle 该 原 则 由Robert C.Martin提出。从面向对象设计的角度看所谓职责是指一个类Class变化的原因。如果一个类有多个改变动机那么这个类就具有多个职责而单一职责原则就是指一个类或者模块应该有且只有一个改变原因。
下面总结一下粒度更细的服务带来的好处
● 粒度更细的服务使每一个服务专注做好一件事情。每个服务完成一个单一任务在功能不变的情况下应用被拆分为多个可管理的服务很好地解决了系统的复杂性问题。
● 粒度更细的服务有助于新人对工程的学习。对于一个大型的、生命周期比较长的项目人员的流动和组织变化是经常发生的事情而庞大的单体架构容易使模块之间相互耦合功能界限模糊同时增加了新人的学习成本。
● 粒度更细的服务有利于部署。对于大型单体项目模块之间往往存在紧密的代码耦合一个子模块的编译错误往往会导致整个应用无法构建成功而细粒度的服务可以通过独立工程解决“牵一发而动全身”的问题。
● 粒度更细的服务具备更好的复用性。在软件领域我们一直提倡使用复用的方式构建系统粒度更细的服务通过独立的部署通过声明语言无关、平台无关的标准接口REST API、gRPC对外暴露服务实现了积木式的架构搭建模式提高了软件整体的开发效率。
围绕业务划分团队传统的IT企业习惯根据人员掌握的技能来划分组织。例如熟悉前端的同事都集中在一个前端开发团队熟悉数据库的同事一般都会集中在DBADatabase Administrator数据库管理员团队熟悉测试的同事专门成立一个测试团队专职做测试工作。我们习惯于将这样的团队称为“职能型组织”它的优势是资源集中有利于同一职能内部的专业人士交流和经验积累。
然而职能型组织最大的问题是团队之间不容易协调利益冲突容易形成部门墙或者叫部门壁垒。当职能部门有多个项目同时进行时就会产生资源失衡问题不利于各职能部门之间的沟通交流和团结协作。业务的需求变化如果牵涉多个职能型组织所负责的模块协作联调往往会出现项目排期问题、优先级问题对于跨地域、跨国家的组织还会出现时差问题、沟通及文化差异问题这个时候反而增加了团队之间的沟通和协调成本降低了开发效率。
微服务架构更加提倡以业务为中心强调围绕业务领域来划分团队。团队由具备不同能力象限的人员组成而这样的全功能型团队相比职能型团队可以防止人员之间的互相扯皮、互相指责的问题。同一个团队围绕业务领域沟通效率更高团队合作更加积极主动有更强的主人翁意识Ownership。从技术的维度看微服务架构倾向于在指定范围的“业务界限上下文”中定义标准规范的交互方式这样能够保证业务接口API更加稳定在后续服务的迭代升级过程中具备更好的业务兼容性和可演进性。
综上所述在围绕业务构建微服务架构的时候解决的一个本质问题就是人员分工的问题正如康威定律所说任何组织所设计的系统、所交付的软件产品方案在结构上都应该与该组织的沟通结构和组织方式保持一致。下面是组织结构演进示意图。
微服务架构不限定提供服务方所使用的技术栈和技术选型。微服务架构倾向于服务之间使用标准的轻量级的通信协议HTTP完成服务的集成和通信。例如对于性能要求比较高、对网络通信效率比较关注的服务可以使用C语言构建对于文本分析性的业务可以采用Python脚本语言而对于企业应用级的Web项目使用Java语言开发比较合适。可见每一种语言和技术都有其“擅长”的场景和适合解决的问题。
微服务架构提倡数据存储的多样性和独立性。不同的数据存储引擎有各自擅长处理的业务类型数据。对于公司的核心业务即OLTPOnLine Transaction Processing联机事务处理业务可能会采用MySQL这样的关系型数据库。关系型数据库的特点是遵循ACID原则对事务的一致性有更好的支持通过标准的SQL语言就可以方便地实现结构化数据的查询和更新。
在 NoSQL 数 据 库 阵 营 中 对 于 日 志 数 据 可 以 存 放 在Elasticsearch这样的LSM树数据结构存储引擎中适合日志搜索、查询操作对于分布式系统之间的共享数据采用Redis这样的内存引擎在读写效率、高并发性能上有更大的优势如果是文档型数据使用MongoDB这样的文档存储引擎更加高效便利。下面是采用不同编程语言和技术栈配合不同的数据存储类型的技术多样式示意图。
微服务架构提倡在技术多样性的场景中选择最适合的技术栈。
微服务通过使用标准的API接口对外暴露服务给尝试新技术提供了更加友好的架构支持。
然而很多公司也推崇使用统一的编程语言和标准化的技术栈。
统一技术栈的优势也是明显的首先它会带来开发效率的提升单一技术栈的维护成本相对较低新加入的开发人员也能够尽快适应统一的编程语言和架构风格项目的风险相对比多技术栈有更好的可控性。
即便如此我们说微服务架构还是向着异构化、技术多样性的趋势在发展因为只有保持技术的多样性才能保证技术生态的生命力。对于技术栈和技术选型来说架构师需要一个Trade-off权衡利弊的过程。
去中心化大型企业在集成异构系统和完成进程之间的通信时一种传统的架构模式就是使用ESB消息总线技术它可以完成信息路由、业务规则编排、协议转化等功能。虽然ESB架构改变了传统软件的架构模式消除了不同应用之间的技术差异协调了不同应用服务的协作运行方式实现了服务之间的集成和整合但是ESB架构倾向于使用集中式的架构管理模式它本质上是一种中心化的架构。我们将这种企业服务总线或服务编配系统的方案称为“智能管道和哑终端”模式它会导致业务逻辑的中心化和哑服务问题。
“哑终端”Dumb Endpoint会导致ESB消息总线过度复杂这种中央式的架构模式存在天然的技术与业务耦合问题。业务编排和业务消息转化能力与业务功能全部集中在单一逻辑控制单元中它并没有做很好的业务封装而是将业务逻辑的复杂性全部传递到了消息总线中。同时随着服务规模的扩大中心化架构的可扩展性会成为一个极大的障碍。业务中的职责边界不清和ESB中心化的问题还会暴露性能问题成为系统的瓶颈。
微服务架构摒弃了ESB的设计理念在微服务架构中服务使用智能端点Smart Endpoint模式。智能端点强调所有的业务逻辑应该自包含在业务内部的处理逻辑单元中它可以确保在服务限界内服务的内聚性而服务之间的通信应该尽量轻量化和简单化。同时微服务使用哑管道Dumb Pipe通信机制将业务无侵入的公共组件抽象出来封装在通用的消息基础设施中API网关、消息中间件等。
我们把微服务架构这样的设计理念称为“去中心化”。微服务架构倾向于服务之间订立标准化的服务契约目标是通过明确清晰的服务边界和服务契约机制让服务可以各自独立迭代和演进。
为了最大化微服务能带来的自治性我们需要给拥有服务的团队委派决策和控制权。去中心化管治的最高境界就是亚马逊所宣扬的“构建并运行它”的理念团队对构建的软件的方方面面负责。
自动化运维微服务架构的采用也引入了很多复杂性关键问题是我们不得不管理大量的服务。微服务增大了运维负担有更多的东西需要部署有更多的地方需要监控错误自然也成倍增加。而解决这些问题的一个关键方法就是拥抱“自动化文化”。前期花费一定的成本构建支持微服务的工具是很有意义的比如自动化测试保证开发迭代中的代码质量使用自动化发布工具将微服务部署到各个环境使用配置文件来明确不同环境间的差异创建自定义镜像来加快部署创建全自动化的不可变服务器。
自动化一直是软件系统运维的最佳实践也是微服务架构强调的重要特性。云技术使得底层基础设施及运行在之上的组件自动化变得非常简单。尽管前期投入通常会更高但从中长期来看无论是人力运维成本还是在系统的弹性和性能方面几乎总能获得更多的回报。自动化可以比人更快地修复、扩展和部署系统。
自动化贯穿软件生命周期的整个过程在持续集成领域我们经常使用Jenkins等工具自动构建、测试和部署微服务软件包。微服务不仅应该自动化部署还应该努力实现金丝雀测试和回滚等过程的自动化。
除非系统负载几乎从未发生变化否则应该根据负载的增加对微服务进行自动扩展并根据负载的持续下降进行自动收缩。通过扩展可以确保服务仍然可用通过按比例收缩可以降低成本。
随着微服务及云原生架构的大规模推广和使用部署和运维的复杂度会逐渐从业务端下沉到以Kubernetes为代表的基础设施PaaS平台利用云和微服务架构我们可以更加快速地部署和交付我们的服务围绕快速交付的基础设施建设是微服务架构规模化发展的首要任务。
快速演进软件的固有特性随着时间的推移会变得越来越难以改变软件的组成部分会因为各种各样的问题变得脆弱难以操作。软件和现实世界一样当人类的需求和环境供给达到平衡时世界是美好的然而当这种平衡因为虫害或者气候变化被打破时人类需要向生态中引入变化重新建立平衡。对于软件系统同样存在这种动态的平衡我们需要提早对系统进行规划和设计。
尽管很多人喜欢在一个理想的环境下来讨论架构然而对于庞大复杂的单体架构很多因素可能促使我们将混乱引入系统工程业务需求的快速变化、工作任务的优先级冲突、有限的人力资源和预算、软件工程师水平的参差不齐、缺乏规范的开发流程和部署方式。另外如果是遗留系统还会存在代码版本混乱、冗余的代码逻辑等技术债务。这种技术包袱总会带来灾难性的后果。通常业务人员往往不想放弃还在工作的系统而开发人员面对单体系统的腐化只能通过不断地堆叠功能完成任务。不停地做加法架构成为塞满各种功能和修复逻辑的庞然大物最终产生破窗效应。而这种架构上的缺陷也将持续加重我们的技术债务业务人员要么忍受这样糟糕的设计、不断地妥协要么丢弃已有系统推倒重来这样的做法对于资源有限的团队和公司来说显然是难以承受的。
微服务架构强调在项目早期将软件分成若干个阶段及不同的模块从时间、业务维度及架构维度上做水平和垂直化的分解。微服务构建的首要任务就是理解业务的问题域好的架构师会充分考虑业务领域的内聚性降低业务之间的耦合寻求两者的平衡并将架构的可扩展性作为重要的设计考量因素。微服务架构的一个特征就是面向架构演进微服务架构的目标正是通过业务领域的边界划分、通过服务的隔离来分解问题逐个击破因此微服务架构天然具备了可演进性。
本文给大家讲解的内容是微服务架构深度解析微服务的主要特性有哪些