微服务架构的优缺点

Posted 2023-05-05

优点：易于开发和维护:一项服务只关注一项特定的业务功能，业务清晰，代码量少。
微型服务的优点:
1.易于开发和维护:一项服务只关注一项特定的业务功能，业务清晰，代码量少。开发维护单项微服务相当简单。整个应用程序由一些微型服务构建，因此整个应用程序处于可控状态。
2.单一服务启动快:单一服务代码少，启动快。
3.局部修改易于部署:单个应用程序只要有修改，就必须重新部署整个应用程序，微服务解决了这个问题。一般来说，修改某个微型服务，只需重新配置该服务。
4.技术堆栈不受限制:微服务结构可结合业务和团队特点，合理选择技术堆栈。例如，一些服务可以使用关系数据库mysql，一些服务可以使用非关系数据库redis。甚至可以根据需服务可以使用JAVA开发，一些微服务可以使用Node.js开发。
5.按需收缩:可根据需要实现细粒度的扩展。例如，系统中的某个微服务遇到瓶颈，可以结合微服务的特点，增加内存，升级CPU，增加节点。
微型服务的缺点:
1.运输要求高:更多的服务意味着更多的运输投入。在单体结构中，只需保证一个应用程序的运行，在微服务中，需要保证几十到几百个服务器的正常运行和合作，这给运行维护带来了巨大的挑战
2.分户式固有的复杂性:使用微服务结构的是分布式系统。对于分布式系统，系统容错，网络延迟带来巨大挑战。
3.界面调整成本高:微服务之间通过界面通信。 参考技术A

微服务架构概述

微服务架构风格是一类将单一应用程序作为由众多小型服务构成之套件加以开发的方式，其中各项服务都拥有自己的进程并利用轻量化机制（通常为HTTP源API）实现通信。这些服务围绕业务功能建立而成，且凭借自动化部署机制实现独立部署。

微服务的特点

应用程序逻辑分为明确定义的职责范围的粒度组件，这些组件相互协调提供解决方案

每一个组件都有一个小的职责领域，可以完全部署，也就是说一个服务可以跨越多个应用程序复用（独立部署和维护）

服务之间通信基于一些基本的原则，比如服务采用http+json这样的轻量级通信协议，在不同服务之间进行数据交换。这样不同服务可以使用不同的技术栈，互不影响（采用轻量级的通信协议作为通信原则、松耦合）

拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。（服务可治理，可管控）

微服务架构的优点

每个服务都比较简单，只关注于一个业务功能。

微服务架构方式是松耦合的，可以提供更高的灵活性。

微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。

每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。

微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。

微服务结构的通用性

通过服务实现应用的组件化（按功能拆分、可独立部署和维护）

围绕业务能力组织服务，根据业务不同的需求进行不同组件的使用

所做产品非项目化，对于平台具有一定的通用性

微服务的缺点

运营成本的增加，整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。

开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。

把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。

“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。

作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。

在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。

聊聊微服务架构的优缺点

什么是微服务

微服务是用一组小服务构建的一个应用，服务运行在不同的进程中，服务之间通过轻量的通讯机制进行交互，并且服务可以通过自动化部署方式独立部署。正因为微服务架构中，服务之间是相互独立的，所以不同的服务可以使用不同的语言来开发，或者根据业务的需求使用不同类型的数据库。

微服务是相对于它出现之前的巨大单体应用来讲的，我们以电商系统为例进行说明，通过以下两张图直观的感受下单体应用与微服务的差异。

优点

1、服务解耦

将原有的巨大的单体应用拆分为多个独立的微服务，使得每个服务更专注于自己的业务，满足高内聚低耦合的设计原则。比如将电商服务差费为用户服务、账户服务、商品服务、购物车服务、订单服务等。

2、独立的开发环境

将应用拆分为独立的微服务，服务之间彼此隔离，通过轻量级的通讯机制（比如：dubbo）进行交互，使得开发时无需关注具体的开发环境，只需要协商好通讯机制即可。

3、独立的部署环境

微服务拥有独立的开发环境，因此需要根据各自的开发环境规划部署环境，对于访问量大的服务可以增加服务的部署数量，访问量小的服务适当的减少部署数量。

4、更高的扩展性

基于服务的独立性，服务之间的耦合性降低，无论从功能上，还是架构上，我们都可以进行更为灵活的扩展，而不影响其他服务。

缺点

1、通讯机制的不标准问题

微服务之间相互独立，但是服务间的交互需要依赖规范的通讯机制，没有规范的通讯机制作为桥梁，服务间交互将变得非常复杂。保证规范的通讯机制，是微服务的前提。

2、事务一致性问题

单体应用通过数据库事务保证一致性，拆分为微服务后，会形成分布式处理的业务，进而就会产生分布式事务一致性问题。分布式系统的事务一致性本身就是一个技术难题，目前没有一种很简单很完美的方案能够应对所有场景。分布式系统的一个难点就是因为“网络通信的不可靠”，只能通过“确认机制”、“重试机制”、“补偿机制”等各方面来解决一些问题。在综合考虑可用性、性能、实现复杂度等各方面的情况上，比较好的选择是“异步确保最终一致性”，只是具体实现方式上有一些差异。

3、服务间的依赖变得复杂

需要根据业务的重要性进行系统梳理，定义出关键业务和非关键业务；梳理服务调用的主要路径，明确强弱依赖、限流、降级规则等。服务治理就是基于以上规则进行的，否则无法进行系统运维或管理。比如非关键业务被关键业务所依赖，会导致非关键业务变成关键业务，服务链中就会出现“木桶效应”，即整个服务质量由最差的那个服务所决定。

数据库也需要做相应的隔离：避免非关键业务把数据库拖死，进而导致全站不可用。不允许直接读取对方的数据库进行系统交互，只允许通过服务接口进行系统交互。这也是微服务的要求：拆分服务和相应数据库。

应避免服务间的循环调用，如果产生循环引用，需要通过架构层面解决循环问题，避免因循环引用导致的系统奔溃问题。同时要对接口进行降级、限流控制，以应对系统的高并发。

4、微服务运维变得复杂

微服务的架构一般会包含基础层、中间件层、应用层、接入层、安全层，同时需要有相应的团队负责各层的运维。各层之间有比较明确的职责，共同支撑着整个系统的运行。一旦某个环节出现问题，整个系统就会像 “多米诺骨牌”一样倒下。因此需要统一的运维平台，实时监控服务调用链路，及时发现和定位问题。而建立统一的运维平台的成本和难度是相当之大的，目前也只有几家互联网大公司拥有这种能力。

5、系统监控变得复杂

对系统的监控依赖于系统的调用链路，链路中包含：http请求、服务间调用、消息队列、数据库、nosql、线程间调用等，如何将监控整个链路将变得非常困难，可能需要修改各中间件的请求数据包。

6、系统测试变得复杂

由于服务的依赖变得复杂，在进行系统测试时，要考虑服务间强弱依赖、降级、限流等问题。在进行压测时要考虑依赖的服务的性能。在制造测试场景时应充分考虑各服务的数据量，避免出现测试误差。

以上内容是本人关于微服务优缺点的思考。文章内容仅代表个人观点，如有不正之处，欢迎批评指正，谢谢大家。