关于微服务:激进技术派-vs-项目保守派的微服务架构之争

72次阅读

共计 2332 个字符，预计需要花费 6 分钟才能阅读完成。

近些年越来越多的企业开始建设本人的微服务体系，在选型过程中不可避免地会产生路线之争。激进的技术派往往秉持着买新不买旧的思维，动摇地站在服务网格的一边。而绝对激进的我的项目派则会更看重技术的稳定性和易用性，从而主张优先下马传统的微服务计划。如果是你，你会怎么选呢？

在答复之前，不如先来尝试答复几个问题：

什么是微服务？
你所在的企业尝试构建微服务体系的目标是什么？是遇到了什么挑战了吗？
你理解服务网格吗？你晓得它是带着怎么的使命诞生的吗？

以上的问题如果你能疾速给出答案，我置信你在微服务选型上的论断应该是通过三思而行的。如果以上的问题让你迷茫，不如和我一起梳理一下微服务的逻辑。

提到微服务可能大部分人首先想到的是 Spring Cloud、Dubbo 或者 Istio。事实上，这种意识是有肯定的局限性。严格来讲微服务就是它字面上的意思，是指微型的服务。而咱们常说的 Spring Cloud、Dubbo 和 Istio 则是微服务架构思维的具体实际。当然，只理解这些那几乎就是废话文学，咱们更想要晓得的是咱们为什么须要微服务？微服务化能够带来什么益处？

应该说任何一种架构的衍进都会明确指向上一代架构的外围痛点，而微服务最后所针对的痛点就是集中式和紧耦合。所有经验过上一个时代的程序员恐怕都会对系统代码的“牵一发而动全身”印象粗浅。

微服务通过将服务拆分胜利能绝对简略且能互联互通的微型模块，实现了业务的充沛解耦，更具独立性的服务拆分形式也使得微服务更合乎分布式部署的需要。微服务体系还带来了其余的劣势，比方：故障隔离能力晋升、可扩展性加强、代码复杂度升高等。从此技术大神们心心念念的高内聚、低耦合有了更亲民的实现形式，而方兴未艾的分布式也有了更多用武之地。

当然像所有的事物一样，微服务也不是完满的。彻底碎片化的服务尽管升高了代码复杂度，却使架构复杂度大大晋升了，这就导致服务互相发现和品质问题的追踪变得艰难。同时，分布式导致的事务问题也突显进去。对于我的项目的设计人员而言，如何正当地布局每一个微服务的性能，也变成了一个须要重复纠结的辣手问题。

经常听到有人说服务网格（Service Mesh）是下一代的微服务技术，Service Mesh 会取代以 Spring Cloud 为代表的第一代微服务架构技术。对此笔者有不同的认识。

以 Spring Cloud 为代表的微服务架构与服务网格的最大差别其实在于代码的侵入性。通常状况下 Spring Cloud 架构的程序在设计时须要与业务逻辑通盘考虑，它尽管不会侵入业务，却沉闷在业务代码呈现的各个角落。

而服务网格技术则齐全采纳了非入侵的解决形式，sidecar 成为了业务服务的惟一代言人。以前须要业务零碎三头六臂能力实现的服务发现、流量治理等工作，当初转为由管制面和 sidecar 组成的这个业余团队来打理了。

由此可见，在解决微服务遇到的问题方面，服务网格技术和以 Spring Cloud 为代表的微服务架构技术的根底思路并没有本质区别，只是在具体的实现门路下面存在显著的差别。

应该抵赖服务网格技术的呈现是基于技术人员对业务与治理能力进一步拆散的诉求而产生的，但由此就说服务网格是微服务的 2.0 时代，还为时尚早。在笔者看来，现阶段服务网格技术更像是微服务技术的半代降级款。

山无常势，水无常形，我的项目中抉择什么样的技术架构并没有一定之规。就像咱们下面提到的，老架构必然在应用过程中弊病丛生，而新架构也同样会带来新的问题。不能说最先进的架构就是最好的，同理最古老的架构也并不是没有存在的价值。所有的抉择都应该基于企业与我的项目的现实情况。

那么咱们应该考量哪些因素呢？

我的项目的目标或产品的倒退阶段。如果我的项目的目标在于验证某种技术或业务计划，或者产品尚处于 MVP 验证阶段，请从微服务架构的迷思中移出你的注意力，出于疾速开发的思考单体架构是你最优的抉择。
业务的规模和市场预期。微服务当然有足够的劣势让人心生向往，然而绝不应该为了技术而抉择技术。一个日活足够高的 2C 场景当然须要微服务，一个交易量足够大的 2B 场景也离不开微服务的保障。然而小而美的垂直畛域却不肯定须要微服务的加持。
技术人员储备。技术的外围价值在于人，对于企业而言进行微服务革新之前最好先盘盘手头的人力资源。Java 语言领有更多的开发者，人力老本绝对较低，Spring Cloud 和 Dubbo 就很适宜 Java 程序员较多的企业。Kubernetes 和容器技术是当下风行的云原生技术的重要根底，相干的运维人员和开发者的薪资也水涨船高，如果企业中这类人员的积攒不错的话，应用与云原生亲和力更强的 Service Mesh 计划也很不错。
我的项目资源状况。我的项目永远是用无限的资源实现确定范畴的工作。一个只会运行在虚拟机环境的我的项目，其实没有必要强行应用 Service Mesh。一个非 Java 语言开发的零碎，也没有必要为了应用 Spring Cloud 而强行重构为 Java 零碎。
对申请提早的容忍水平。Sidecar 在带来便利性的同时，也带来了额定的延时。以 Istio 应用的 Envoy 为例，官网的测试论断为每通过一次 sidecar 就会产生 3ms 左右的提早，对于个别的利用零碎而言 3ms 是一个齐全能够承受的数字。然而对于调用链路极深的简单业务零碎而言，链路上的 sidecar 所积攒进去的延时将是一个较大的数字。而在一个对延时十分敏感的场景中，3ms 是不是一个能够承受的数字也须要充分考虑。

篇幅无限笔者无奈也不可能穷尽所有的状况，以上内容只是抛砖引玉。技术终不过是咱们实现事实目标的一种伎俩而已，善加利用砖头也是一代神兵利器。

正文完