初探：微服务架构原来是这样的

悠悠 2022-08-28 02:51 56阅读 0赞

任何IT项目都是有生命周期的，总会有消亡的一天，框架更好的项目活的会更久点，使用不好的框架项目，上线既是死期。框架是一种手段，并非是项目长期成功运行的基础，只能让项目健康的活的更久点。

![b9dc56211000b4fd7fae3cf603a0b2ab.png][]

微服务架构（MicroserviceArchitecture）是一种架构概念，本质上就是将一个大型、复杂的业务进行拆分成多个小服务，每个小服务可以独立运行、提供范围有限的功能（可以是业务功能、也可能是非业务功能）的组件，这些服务之间通过某种协议（REST、RPC等）进行互相协作，从而完成了原单体架构下的业务功能，但这种情况下的业务部署更加灵活、易扩展、开发难度降低。对于微服务来说，其中一个关键点就是各服务之间的松耦合，各服务之间通过某种“标准”的协议进行沟通，不需要理解对方服务的实现逻辑、实现方式，只要在对方所提供的服务接口没有变化的情况下不会影响自己所提供的服务功能即可。总而言之，微服务核心思路就是**分而治之**。

![68025878248f9f5088268e338da714c8.png][]

微服务的设计理念参考了UNIX系统，即每个服务仅承担一种责任。简单来说，微服务技术就是一系列服务的集合体。

![ce200f23f36006dfef8569fe3f7c8713.png][]

（1）微服务优点如下：

关键点：复杂度可控、独立按需扩展、技术选型灵活、容错、高可用性

*  松耦合：基于微服务架构的应用是一系列小服务的集合，这些服务之间通过某种通信协议进行通信（比如REST、RPC或者消息驱动的API），这样只要原接口没有改变，就不会对服务消费者造成任何影响。
 *  抽象：一个微服务对其数据结构和数据源拥有绝对的控制权，只有该服务才可以对数据做出修改，其他微服务只有通过该服务才能访问数据。因此，该服务可以很方便地对所能提供的数据进行有效控制。
 *  独立：每个微服务都可以在不影响其他微服务的情况下进行编译、打包和部署，这是单体架构应用无法做到的。
 *  应对用户需求的多样性：微服务架构可以让我们轻松应对不同客户的特殊需求，通过定义良好的接口，可以让不同微服务承担不同的责任，同时快速部署上线能力可以让用户需求尽早实现。
 *  高可用性：微服务架构可以认为是一个去中心化的应用，每个微服务都可以随时上线或下线。当某一个微服务出现问题时，只需要将其下线即可，其他同类型的微服务将承担其功能，对外仍旧可以提供服务，不会造成整个服务无法正常工作。

由于每个微服务都足够小，开发人员可快速理解与掌握，项目工程代码少，不会造成IDE速度变慢，开发和调试速度也会非常有效率；每个服务可依据其特性、开发人员技术特长，选择不同的技术栈（开发语言和框架）进行开发；容易重构或重写，并选择相应的开发语言和框架（含使用新的开发语言和框架）；可在低风险情况下，对项目系统进行升级改造（含使用新的开发语言和框架），而不致使整个项目无法正常使用；通过微服务架构的实施，可以灵活地开发、运维、升级。

（2）微服务的缺点：

关键点：服务间通信成本，数据一致性，多服务运维难度，系统集成测试

*  分布式系统的复杂性：分布式系统跨进程、跨网络的调用，受网络延迟和带宽的影响较大。微服务之间通过远程调用进行协作，而远程调用高度依赖网络状况，任何一次的调用都有可能失败，随着服务的增加，潜在的故障也会增加。如果没有有效的方案，微服务架构可能会大大降低应用的可用性。此外，异步通信也大大增加了功能实现的复杂度，并且伴随着定位难、调试难等问题。
 *  处理分布式事务较棘手：当一个用户请求的业务涉及多个微服务时，如何保障数据的强一致性就成了一个棘手的问题，需要在 CAP原则\{ C（一致性）A（可用性）P（分区容错性）\}三者之间做出权衡。传统开发可以通过使用两阶段提交的解决方案来解决这个问题，但对于微服务来说，这个解决方案并不是一个优解，甚至在某些情况下很难实现；
 *  测试：服务间的依赖测试单块架构中，通常使用集成测试来验证依赖是否正常。而在微服务架构中，服务数量众多，每个服务都是独立的业务单元，服务主要通过接口进行交互，如何保证依赖的正常，是测试面临的主要挑战。此外，服务数量众多，如何清晰有效地展示服务间的依赖关系也是个不小的挑战；
 *  学习难度曲线加大：虽然微服务架构可以将服务进行分解，但需要开发人员掌握一系列的微服务架构开发技术，加大了入门门槛；
 *  组织架构变更：DevOps 与组织架构在微服务架构的实施过程中，开发人员和运维人员的角色发生了变化，开发者将承担起整个服务的生命周期的责任，包括部署和监控；而运维则更倾向于顾问式的角色，尽早考虑服务如何部署。虽然对于单独一个微服务的部署进行了简化，但是整体应用部署的复杂度提升了，需要涉及服务编排和服务治理等一系列处理，即不仅需要制定微服务之间的部署安排、关联关系、回滚计划等，还需协调不同的团队，以及在人事组织上进行调整来适应这种变化。
 *  运维成本提升：运维主要包括配置、部署、监控与告警和日志收集四大方面。微服务架构中，每个服务都需要独立配置、部署、监控和收集日志，成本呈指数级增长。此外，每个服务都独立部署，交付周期短且频率高，人工部署已经无法适应业务的快速变化。因此如何有效地构建自动化部署体系，是微服务面临的另一个挑战。

![008dcae4d28d789b97829546d85c3eb5.png][]

到目前为止，并非所有项目都适合微服务架构技术，还需依据业务的实际发展与需求，在实践中正确选择微服务架构。

[b9dc56211000b4fd7fae3cf603a0b2ab.png]: /images/20220828/13655d8626cf4839ab90ed586e5614cf.png
[68025878248f9f5088268e338da714c8.png]: /images/20220828/4f954e0fbbdf4107961eb8c8c56a57d9.png
[ce200f23f36006dfef8569fe3f7c8713.png]: /images/20220828/d91cb2b2c3e841b18a4f13e71b32d124.png
[008dcae4d28d789b97829546d85c3eb5.png]: /images/20220828/cc73eb816e40489c98587817be85cbc3.png