微服务架构深度解析：你知道微服务的主要特性有哪些吗？

● 粒度更细的服务使每一个服务专注做好一件事情。每个服务完成一个单一任务，在功能不变的情况下，应用被拆分为多个可管理的服务，很好地解决了系统的复杂性问题。

● 粒度更细的服务有助于新人对工程的学习。对于一个大型的、生命周期比较长的项目，人员的流动和组织变化是经常发生的事情，而庞大的单体架构容易使模块之间相互耦合，功能界限模糊，同时增加了新人的学习成本。

● 粒度更细的服务有利于部署。对于大型单体项目，模块之间往往存在紧密的代码耦合， 《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源威信搜索公众号【编程进阶路】 一个子模块的编译错误往往会导致整个应用无法构建成功，而细粒度的服务可以通过独立工程解决“牵一发而动全身”的问题。

● 粒度更细的服务具备更好的复用性。在软件领域，我们一直提倡使用复用的方式构建系统，粒度更细的服务通过独立的部署，通过声明语言无关、平台无关的标准接口（REST API、gRPC）对外暴露服务，实现了积木式的架构搭建模式，提高了软件整体的开发效率。

围绕业务划分团队

========

传统的IT企业习惯根据人员掌握的技能来划分组织。例如，熟悉前端的同事，都集中在一个前端开发团队；熟悉数据库的同事，一般都会集中在DBA（Database Administrator，数据库管理员）团队；熟悉测试的同事，专门成立一个测试团队专职做测试工作。我们习惯于将这样的团队称为“职能型组织”，它的优势是资源集中，有利于同一职能内部的专业人士交流和经验积累。

然而，职能型组织最大的问题是团队之间不容易协调利益冲突，容易形成部门墙或者叫部门壁垒。当职能部门有多个项目同时进行时，就会产生资源失衡问题，不利于各职能部门之间的沟通交流和团结协作。业务的需求变化如果牵涉多个职能型组织所负责的模块协作联调，往往会出现项目排期问题、优先级问题，对于跨地域、跨国家的组织，还会出现时差问题、沟通及文化差异问题，这个时候反而增加了团队之间的沟通和协调成本，降低了开发效率。

微服务架构更加提倡以业务为中心，强调围绕业务领域来划分团队。团队由具备不同能力象限的人员组成，而这样的全功能型团队相比职能型团队可以防止人员之间的互相扯皮、互相指责的问题。同一个团队围绕业务领域沟通效率更高，团队合作更加积极主动，有更强的主人翁意识（Ownership）。从技术的维度看，微服务架构倾向于在指定范围的“业务界限上下文”中定义标准规范的交互方式，这样能够保证业务接口（API）更加稳定，在后续服务的迭代升级过程中具备更好的业务兼容性和可演进性。

综上所述，在围绕业务构建微服务架构的时候，解决的一个本质问题就是人员分工的问题，正如康威定律所说，任何组织所设计的系统、所交付的软件产品方案在结构上都应该与该组织的沟通结构和组织方式保持一致。下面是组织结构演进示意图。

技术多样性

======

微服务架构不限定提供服务方所使用的技术栈和技术选型。微服务架构倾向于服务之间使用标准的轻量级的通信协议（HTTP）完成服务的集成和通信。例如，对于性能要求比较高、对网络通信效率比较关注的服务，可以使用C++语言构建；对于文本分析性的业务，可以采用Python脚本语言；而对于企业应用级的Web项目，使用Java语言开发比较合适。可见，每一种语言和技术都有其“擅长”的场景和适合解决的问题。

微服务架构提倡数据存储的多样性和独立性。不同的数据存储引擎有各自擅长处理的业务类型数据。对于公司的核心业务即OLTP（OnLine 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网关、消息中间件等）。

我们把微服务架构这样的设计理念称为“去中心化”。微服务架构倾向于服务之间订立标准化的服务契约，目标是通过明确清晰的服务边界和服务契约机制让服务可以各自独立迭代和演进。

微服务架构深度解析：你知道微服务的主要特性有哪些吗？相关推荐

微服务架构深度解析与最佳实践
微服务架构深度解析与最佳实践微服务架构的概念,现在对于大家应该都不陌生,无论使用 Apache Dubbo.还是 Spring Cloud,都可以去尝试微服务,把复杂而庞大的业务系统拆分成一些更小粒 ...
25岁阿里120W年薪架构师推荐学习的750页微服务架构深度解析文档
前言当前,微服务架构在国内正处于蓬勃发展的阶段,无论是大型互联网公司还是传统的IT企业,纷纷采用微服务架构构建系统. 在过去几年里,DevOps.云原生.面向演进式架构等理念已经深入人心,围绕微服务 ...
你知道微服务架构深度解析：微服务的主要特性有哪些吗？
微服务主要特性粒度更细的服务微服务架构相比SOA分布式架构强调按业务边界做细粒度的服务拆分.SOA架构使用粗粒度的服务模式来封装业务和技术能力,减少服务交互,但同时带来了业务耦合的复杂性.而微服务 ...
微服务架构深度解析与最佳实践-第一部分：微服务发展历程和定义
微服务架构的概念,现在对于大家应该都不陌生,无论使用 Apache Dubbo.还是 Spring Cloud,都可以去尝试微服务,把复杂而庞大的业务系统拆分成一些更小粒度且独立部署的 Rest 服务 ...
微服务架构深度解析与最佳实践 - 第五部分：七个应对策略之性能、一致性与高可用
七个关键问题的应对策略-续 3.关于微服务对性能的影响大家可以先思考 2 个问题:延迟(latency)和吞吐量(throughout)有什么关系? 延迟是响应时间么? 先说一下延迟和响应时间,延迟 ...
微服务架构深度解析与最佳实践 - 第七部分：全文总结与引用材料
最佳实践的总结林林总总说了这么多的微服务架构相关的知识也好,经验也罢,不一定适合每个希望做微服务系统的技术人员的实际需求."道无常道,法无常法,君子审时度势,自可得而法".实际项 ...
【架构实践】微服务架构全解析：Scale Cube 横向扩展，垂直扩展，纵向扩展
目录微服务架构全解析:Scale Cube 横向扩展,垂直扩展,纵向扩展前言
微服务架构(一)：什么是微服务
解析微服务架构系列文章将分几篇描述微服务的定义.特点.应用场景.企业集成架构的演进以及微服务转型思路和技术决策考虑等内容,并以IBM技术为例介绍如何实现微服务架构转型. 为什么需要微服务架构 &quo ...
微服务架构(一)：什么是微服务(一)
解析微服务架构系列文章将分几篇描述微服务的定义.特点.应用场景.企业集成架构的演进以及微服务转型思路和技术决策考虑等内容,并以IBM技术为例介绍如何实现微服务架构转型. 为什么需要微服务架构 &quo ...

微服务架构深度解析：你知道微服务的主要特性有哪些吗？

微服务架构深度解析：你知道微服务的主要特性有哪些吗？相关推荐

最新文章

热门文章