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

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注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网关、消息中间件等）。

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

为了最大化微服务能带来的自治性，我们需要给拥有服务的团队委派决策和控制权。去中心化管治的最高境界就是亚马逊所宣扬的“构建并运行它”的理念，团队对构建的软件的方方面面负责。

自动化运维

======

线程、数据库、算法、JVM、分布式、微服务、框架、Spring相关知识

一线互联网P7面试集锦+各种大厂面试集锦

学习笔记以及面试真题解析

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

[外链图片转存中…(img-XZ8Ak0R2-1713681224129)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！