微服务是开发架构对三高场景的妥协吗？

大家好我是酒癫，今天我来浅谈一下微服务架构，是否是对主要为三高场景的妥协这个话题。

前言：

微服务架构是为了解决传统单体架构的缺点，而产生的架构，网上所说的优点一般有如下：

1.独立部署一小块功能

2.快速启动，因为功能更小，所以启动更快

3.分治思想有所表现

4.扩容方便

5.解耦

6.方便维护

其他······

当然微服务也有很多缺点，我们暂时不说缺点，只看优点。我个人从接触微服务框架开始到现在心里一直有个疑问：微服务的架构是否有必要。其实这个话题早在国内外就有很多讨论了，我在这里稍微阐述一下我的观点。

• 首先，微服务框架是为了解决一些问题才出现的，主要解决的问题就是三高场景下，服务的健壮性。确定的一件事是这问题是实际存在的，是需要解决的，只是我认为解决的方式错了，我觉得解决这些问题的“层”或者“人”错了。

• 我认为编码就是单纯的编码，微服务需要解决的问题，应当是云服务平台的职责。

• 编码就是编码，开发人员应该提供的是最简约的原始代码功能，凡项目中涉及微服务的功能都不应该出现，应该交给代理实现，而这个部分如果是云平台的话，应当全权由云平台负责， 这样不仅能大量节省企业的开支，也能让云平台职责更明确。

• 我们从广义看一次请求，从请求-》服务-》响应，然后开发提交的是最纯粹的代码，我们以电商项目为例，首页有压力，现在的解决办法是各种的缓存、延迟、等技术，这些应该是云平台做，部分功能有流量压力，可以动态增加/减少硬件配置，这个也应该是云平台做，因为你多机器部署不是总想省钱么，但是你难道就没发现你就算多机器部署了，还是大多数时间机器都是空闲的吗？这样的话你拆机器部署有何意义呢？所以云平台应当有自己的一套系统，可以动态分配硬件配置支持，实时生效，这样就可以用尽可能少的机器，尽可能 24 小时满配载的情况下，跑业务。你分布式事务为啥？因为业务链或者数据链长，数据存取慢，所以分治处理，比如什么分库，这些应该你开发架构考虑吗？还是云平台做，慢的最根本原因就是性能不够（得加钱）。银行不少业务都是大机器跑，3 位数的核心，内存就更不用说了，需要什么微服务拆分吗，不需要，还简单，没有微服务的缺陷。然后你觉得大机器买的贵，能理解，但这个云平台提供按需使用成本不就下来了。

我不知道上面说的一些东西是否能说服你，或者现在正有人骂我呢，我们就事论事，我认为开发就是单纯编码，性能问题是硬件问题，不应该由开发负责，也就是说微服务架构应当由专门云平台解决，这个云平台可以是企业自建，也可以用现在的云厂商，但说句实话，我现在还没看到能做好这一点的厂商。至于你怎么实现，那是平台的问题，可以理解吧，实际上机器比人贵多了，每秒钟都按需使用，按需结算的云，才是好云。

综上所述，微服务架构，我个人认为就是开发架构在这个阶段对主要为三高场景下的业务环境，的妥协。开发架构做了不应该做的事，代码中揉进了太多业务无关的功能和配置，这样说能理解吧。基于这一点，你就会发现，保持代码纯净才是一个合格开发最应该做的事，你写代码就是完成业务功能的，这件事以外的所有东西都不应该让代码做。

小结：

云平台如何实现动态资源，这可是很有意思的话题，毕竟便宜又稳定，是所有企业的首选，这个是另一个话题了，且听下回分解（时间未定），再引一个话题，如果云平台完美了，如何精简企业开发团队成本（主要是人）呢？