微服务架构思考

时间：2024年06月16日

作者：小蒋聊技术

邮箱：wei_wei10@163.com

微信：wei_wei10

音频地址：

https://xima.tv/1_HvQZkj?_sonic=0https://xima.tv/1_HvQZkj?_sonic=0

大家好，欢迎来到小蒋聊技术，小蒋准备和大家一起聊聊技术的那些事。

今天小蒋准备和大家一起聊的技术就厉害了！那就是微服务！

简介

随着企业业务规模的不断扩大，传统的单体架构已经难以满足现代企业的需求。微服务架构作为一种经过良好架构设计的分布式架构方案，为企业提供了全新的解决方案。

产生原因

服务架构的演变，并不是偶然，它是由诸多因素共同驱动的，比如要解决的问题规模、团队采用的技术栈、追求更快速的交付，希望保证可维护性、可扩展性、可伸缩性，等等。这些因素决定了我们必须要在软件架构上进一步优化，才能应对面临的挑战。

概括来说，软件服务架构经历了单体架构、SOA架构、微服务架构这几种形式。

微服务架构的演变

单体架构

单体架构，指的是在一个应用程序中打包业务场景涉及到的所有功能。例如将一个电商系统完整打包在一个WAR包，然后在Web容器中运行。

当软件规模不是很大的时候，单体架构是比较合适的，开发、测试、部署、监控等相对来说也是比较方便的。但是随着软件规模的扩大，问题会变得越来越复杂。

系统启动慢，由于一个进程包含了所有的业务逻辑，涉及的启动模块过多，导致系统的启动，重启周期变长。
随着系统的发展，业务越来越复杂，单体应用的代码量会越来越大。这就使得在某一模块需要变动时，可能会影响到整个系统，带来很大的维护成本和风险。
对应用程序做任何细微的修改都需要将整个应用程序重新构建、重新部署，带来了不少额外的工作量。
单体架构通常为垂直扩展，也就是只能通过增加硬件资源的方式来提升系统性能，但这种方式的提升空间有限。
难以灵活地扩展或缩小单个功能模块。如果某个模块需要更大的计算资源，而其他模块不需要，单体架构无法单独扩展该模块。
单体架构中所有的模块都在一个应用中，这就导致所有模块都被限制在同一个技术栈中，很难引入新技术。

单体架构有它的简单的优势，但是，企业在选型时还是需要结合业务场景、系统复杂度、未来支撑业务量级，等等，对软件架构做出更科学合理的选型和规划。

分布式架构

为了解决大型软件系统开发中的问题，在单体架构的基础上进行进一步的优化。按照业务功能对原有软件进行垂直拆分，拆分得到多个边界清晰的业务子系统，每个业务子系统依然采用单体架构，每个子系统都可以分布式部署。

和单体架构相比，分布式架构它已经能够按功能进行更细粒度的划分，并且各个子系统能够更细粒度地伸缩。不同的子系统可以交由不同的团队来进行维护，如果需要可以选择不同的技术栈，开发、测试、部署也更顺畅。

分布式架构一定程度上解决了单体架构的不足，但是它仍然存很多问题。比如，按子系统功能垂直拆分粒度过于粗放，各个子系统之间存在数据冗余, 架构设计起来会变得异常复杂，等等。

SOA架构

SOA架构（Service-Oriented Architecture，面向服务的架构），是在分布式架构基础上的进一步优化。将一些公共的基础服务提炼出来，以接口的形式暴露出来给其他服务调用，如将用户管理、单点登录等功能提取出来作为基础服务供各个子系统调用。

各个子系统通过企业服务总线ESB与其他子系统进行交互，具体的可以是通过Web Service、RPC来实现。

SOA架构进一步解决了分布架构存在的问题，它可以将一些公共的功能提炼为基础服务，提高功能复用性，同时这些基础服务、各个子系统也可以进行更细粒度的伸缩，同时，采用ESB也减少了整个系统中服务与服务之间的耦合。

SOA架构也并非就是完美的，比如逻辑层和服务层之间的边界如果拿捏不准，可能导致抽取的基础服务的粒度过大，导致逻辑层过多依赖服务层，耦合严重。另外，引入ESB进一步简化了系统集成的问题，降低了不同服务之间的耦合，但是系统大了之后，各个服务接口的协议也变多，ESB需理解这些协议才能执行后续的订阅分发、转发等操作，协议的维护会变得困难。

微服务架构

微服务架构中对公共功能进行提炼，提炼成一些更细粒度的服务，并以接口的形式对外提供服务。这里的更细粒度的服务，即微服务。

微服务架构和SOA架构有些接近，但微服务架构和SOA还是有区别的。SOA侧重于系统的集成，微服务架构的核心思想就是按照服务功能进行最小粒度拆分。不同的微服务可以由不同的团队负责，根据需求开发人员也可以更自由地选择合适的技术栈进行开发。各个微服务都可以快速迭代、测试、上线，也有助于提高研发效率。

微服务并不是说按照功能把服务粒度拆的更细之后就结束了，它还面临着一系列运维上的挑战。相比单体应用，微服务架构的服务数量多了很多，如何合理有效地管理、监控这么多微服务也是一项巨大的挑战，同时还要考虑对于分布式事务的处理。

单体架构与微服务对比

单体架构（Monolithic Architecture） VS 微服务架构（Microservices Architecture）

单体架构

微服务架构

单体架构被认为是构建应用程序的传统架构方式。单体应用程序是作为一个不可分割的单元构建的。通常，这种解决方案包括客户端用户界面，服务器端应用程序和数据库。

单体架构应用程序是一个统一的整体，而微服务架构则将其分解为较小的独立单元的集合。

在微服务架构中，功能被分解为可独立部署的模块，这些模块通过远程调用方法相互通信。每个服务都涵盖了自己的范围，每个服务可以独立更新，部署和扩展。

简而言之，微服务架构风格是一种将单个应用程序拆分为一组小服务的方法，每个小服务都在自己的进程中运行并使用轻量级机制（通常是HTTP资源API）进行通信。 ----马丁·福勒

单体架构（Monolithic Architecture） VS 微服务架构（Microservices Architecture）

单体架构优势

使用成本低：上手容易，学习成本低，通常技术栈比较简单。
部署简单：易于部署，单体应用部署的复杂度要比微服务低得多。
易于开发：适合小型团队开发“小而美”的，对业务复杂度不高，对应用扩展能力要求不高的应用程序架构。

微服务架构优势

独立组件：首先，所有服务都可以独立部署和更新，从而提供了更大的灵活性。比如：针对IO密集型服务增加内存，针对计算密集型服务增加服务器的CPU，等等，达到资源的合理分配。
业务关注更加集中：将应用程序分解为更小和更简单的组件后，将更易于业务关注理解和管理。您只需专注于与您的业务目标相关的特定服务即可。所以：很多大厂都是面试造火箭，工作拧螺丝。因为微服务化只需要开发人员更专注于自己的服务领域。生产线尽管很庞大，但是只要拆分合理，开发人员只需要拧好自己的“微服务螺丝”就可以了。
更好的可扩展性：微服务另一个优点是每个服务都可以独立缩放。结合容器化编排管理（k8s、docker等），可以快速的实现服务的扩容与缩放。比如：赶上双十一，电商可以快速地增加部署微服务数量以应对更多的并发需求。待高峰过后，可以将微服务容器释放，回收资源。
选择技术的灵活性：工程团队不受一开始就选择的技术的限制。他们可以自由地为每个微服务应用各种技术和框架。只要保证接口通信协议一致即可。

单体架构（Monolithic Architecture） VS 微服务架构（Microservices Architecture）

单体架构缺点

开发复杂度逐步增加：随着应用需求的增加以及规模的扩大，由于其代码耦合度高，单体应用自身的代码复杂度会很高，从而变得难以维护。
维护成本高：修改任何一处细节的代码，都会影响整个系统。因此必须全面协调开发、测试、部署。这使软件迭代变的很慢，交付的效率低。
扩展性差：很难去针对某个模块进行扩展，只能针对整个应用程序扩展。IO密集型和计算密集型模块混合在一起，无法独立升级及扩容。
引入新技术困难：新技术壁垒，在单体应用程序中应用新技术极其困难，因为这样就必须重写整个应用程序。

微服务架构缺点

开发复杂度增加：由于微服务架构是分布式系统，因此会产生分布式的数据库操作及分布式事务等复杂度更高的开发需求。所以一定要进行合理的微服务拆分，合理的确定服务边界，保证服务内部高内聚，降低分布式事务等操作出现的概率。
额外关注：微服务由于其多主机、分布式部署，所以它们需要很多的额外关注，如统一配置，统一日志记录，统一的指标监控，统一的运行状况检查等。
测试难度高：虽然单个微服务的测试复杂度降低，但是众多可独立部署的服务使集成测试变的更加困难。

企业如何选择最适合的架构？

选择单体架构

小团队：如果您是一家初创公司，而您的团队很小，则可能不需要处理微服务架构的复杂性。整体组件可以满足您的所有业务需求，因此无需选择微服务架构。
一个简单的应用程序：不需要大量业务逻辑，小型应用程序与单体应用架构可以更好地协作。
没有微服务专业知识：微服务需要深厚的专业知识才能运作良好并带来业务价值。如果您想从头开始没有任何技术专业知识的微服务应用程序，那么很可能不会成功。
快速应用：如果您要开发应用程序并尽快应用它，则单体应用架构是更好的选择。当您的公司打算花最少的钱验证您的经营理念时，它会很好地发挥作用。

选择微服务架构

用户数量或应用规模庞大：微服务架构使扩展和添加新功能变得更加容易。因此，如果您打算开发具有多个模块和高用户体验的大型并发应用程序时，那么微服务架构可能是您的最佳选择。
团队庞大并有足够的技能：由于微服务项目由负责多个服务的多个团队组成，因此您需要有足够的资源来处理所有流程。包括人力（技术人员）、物力（服务器）、财力等等。
具有微服务专业知识：没有适当的技能和知识，构建微服务应用程序将具有极大的风险。但是仅具有架构知识还不够，还需要有DevOps和Containers专家。此外，必须具有领域建模专业知识。处理微服务意味着将系统拆分成单独的功能并划分职责，合理的划分成就效能，不合理的划分导致灾难。