【20220116】企业究竟要不要搞微服务？

时间：2022年01月16日

作者：小蒋聊技术

邮箱：wei_wei10@163.com

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

“微服务”这两年变得是越来越火，小蒋之前和大家一起分析了“微服务架构演变之路”。有很多小伙伴就给小蒋发消息，小蒋你说“微服务”这么火，为什么我们企业不用，是不是我们企业不行了，是不是该换工作了？

今天小蒋就来和小伙伴一起来看看，究竟一个企业或团队到底是什么原因要使用“微服务”？真的是所有企业都必须用“微服务”吗？是互联网大厂都在用吗？

前言

在技术团队里，总是有一些技术狂热份子，热衷于新架构，新技术，但是对于这些技术究竟解决了哪些业务场景的问题并不关心。所以，这就直接导致了很多技术在不恰当的时候被使用了。

“微服务”这几年是非常火，但是小蒋认为任何一个新的架构的出现，一定是传统架构模式遇到了问题，有些问题无法得到有效的解决，“不得不”重新开辟一条新路。

重新开辟一条新路，可不是一件好玩的事，这里面其实有着巨大的投入。但是，一些企业，比如说类似“京东”这样电商平台，一天的访问量上亿，每秒事务数都是百万级别的（TPS），618大促期间流量更是翻几倍。他们为什么“不得不”也得搞“微服务”？

这是因为这种巨大流量的业务场景下，传统架构已经无法满足业务需要。即使面对“巨大的投入”也“不得不”搞“微服务”。这是为了满足业务需求，根本不是说“微服务”技术有多么先进。

对于架构师来说，应该基于业务、技术、团队资源、成本等多个维度来综合考虑究竟应该在什么时候用什么的技术最合适。

“微服务”主要的优势

1. 单一职责

每个“微服务”节点，都是具有业务逻辑的，可以理解为是一个“小系统”，而且高度“服务化”。符合高内聚、低耦合、单一职责。

通过微服务架构，将“微服务”节点通过“管道”的方式灵活组合，从而构建出庞大的整体系统。

1. 轻量级通信

通过RPC框架或者REST模式，通过事件流和消息代理的组合方式相互通信，实现“服务”与“服务”之间的轻量级通信机制。

1. 独立性

在“微服务”架构中，每个服务都是独立的业务单元，与其他服务高度解耦，内部业务逻辑调整时，只需要改变当前服务本身，就可以完成独立的开发、测试、部署、运维。

1. 进程隔离

“微服务”架构中，每个“微服务”节点都是高度自治的独立系统，可以运行在独立的进程中，不同的“微服务”能非常容易的部署到不同的服务器节点上，这样可以实现“微服务”高度自治和高度隔离。

因为进程的隔离特性，所以有利于“微服务”的动态扩容。当业务高峰期时，可以根据系统负载自动增加服务资源，提升系统并发能力和吞吐量；当业务低谷期时，则可以自动释放服务资源，以节省开销。

1. 混合技术栈和混合部署方式

通过以上的几个特点，我们可以明白。“微服务”其实就是独立的“子系统”，通过一种相同约定进行通信。

所以每个“微服务”其实可以根据业务需要，选择不同的技术栈开发，使用不同的部署方式。（公有云、私有云、混合云）

1. 单独管理

每个“微服务”集群，可以根据业务需要单独扩容和释放。从而避免了“系统”必须整体进行扩容和释放而产生的浪费和成本开销。

“微服务”架构要解决的问题

“微服务”是一个新的架构模式或方法，它的出现表示着传统架构模式遇到了问题。

通过上面我们一起看到的微服务的优势，小蒋总结了一下，微服务架构主要就是要解决如下几个问题：

1. 单体应用规模太大，导致的系统复杂度增加，难以开发和管理。
2. 单体应用开发、交付、变更周期变长，敏捷性跟不上。
3. 单体应用本身的性能，扩展性上都出现了问题。无法有效的进行动态扩容。

微服务架构实际上是传统组件化架构思想的进一步强化，强化的核心就是独立和解耦。

不过，咱千万不能高兴的太早了，有优势必然有劣势，能量肯定是守恒的。

小蒋和大家再来一起分析一下“微服务”的劣势。

“微服务”带来的一些问题

1. 分布式系统的复杂性

微服务架构是基于“分布式的系统”，“分布式系统”天生就会带来额外的开销。

1. 性能：分布式系统是跨进程、跨网络的调用，必然会受到网络抖动、延迟、带宽的影响。
2. 可靠性：Rest 和 RPC 都是属于远程调用，高度依赖网络状况。任何一次的远程调用都有可能失败，随着“微服务”节点的增多，还会出现更多的潜在故障点。所以，网络可靠性是微服务架构的一大挑战。
3. 分布式通信：经常能听到开发的同学抱怨，对方的服务不可用、问题定位难、调试困难，等等。分布式通信大大增加了系统的实现复杂度。
4. 数据一致性：做研发的小伙伴，肯定听过CAP，也就是C（一致性）、A（可用性）、P（分区容错性），这三个不可能同时做到，只能选择其中两个。微服务架构引来的一个大问题就是“分布式事务”。

1. 服务的依赖管理和测试

单体应用中，通常使用集成测试来验证依赖是否正常。但是，在微服务架构中，因为服务数量非常多，每个服务都是独立的业务单元（子系统），服务主要是通过接口进行交互，在测试工作中如何保证每个服务的业务正常，是测试面临的首要挑战。

所以，单元测试和单个服务链路的可用性测试非常重要。

1. 服务的版本控制管理

单体系统中，配置可以写在properties或者yaml文件中。但分布式系统中需要统一进行配置管理，同一个服务在不同的场景下，配置可能是不同的。所以要引入配置的版本管理、环境管理，这又增加了系统复杂度。

1. 自动化部署流程

在微服务架构中，每个服务都要独立部署，交付周期短而且频率高，人工部署已经无法满足架构和业务上的快速变化需求了。所以，微服务架构，需要有一套自动化部署体系，配合网络、容器技术、自动化技术。这是微服务架构带来的另一个挑战。

1. 运维成本

系统运维中，主要包括配置、部署、监控与告警、日志搜集这四个方面。微服务架构中，每个服务都要独立的配置、部署、监控、日志收集，所以运维成本呈指数级增长。

服务化粒度越细，运维成本越高。

以上这些问题，都是微服务架构必须面临的挑战。

“微服务”架构要解决的问题（二）

咱们聊完微服务架构的“优势”和“问题”以后，再来回顾一下微服要解决的问题，这样自然就更加清楚了。

1. 微服务是传统单体应用的拆分，而且要做到高度独立自治。
2. 微服务的拆分，不仅仅是功能的拆分，更加是数据上的拆分。
3. 异步和解耦是微服务架构设计的重要指导思想。
4. 微服务间通过RPC框架或者高效的Rest API接口交互协同。
5. 微服务实践需要开发组织、持续集成、测试、交付方式多个体系共同配合支撑。

传统企业要不要搞微服务架构？

传统企业要使用微服务架构，就一定思考微服务架构究竟能解决什么问题。如果，这个问题没有想清楚就不要轻易去使用微服务架构。

小蒋个人认为，技术绝对不是越新越好，越热越好。而是要考虑业务使用场景，从多个维度综合考虑究竟该在什么时候用什么样的技术最合适。

总结

微服务架构看似解决很多单体架构的痛点，但是同样也增加了架构的难度、测试的难度、运维的难度。在软件行业“能量守恒”这个定律也一样是适用的。

架构师要做的就是根据具体的“业务场景”，找到适合的框架、适合的方法、适合的迭代模式。并不是一味地最求“所谓的新”。

小蒋个人认为：“框架、方法、模式要做到在业务场景中相对的平衡，没有任何一种“架构/技术”可以通吃所有业务场景，必须因地制宜”。

年龄的增长不可怕，可怕的是从未成长！

感谢大家支持小蒋，小蒋希望和大家共同成长，谢谢。

音频版地址：

企业究竟要不要搞微服务？https://www.ximalaya.com/keji/51588599/493015614