6问微服务到底靠不靠谱？ _微服务

最近看到一个新闻，说是内容是 “IBM、甲骨文、CNCF 就谷歌对 Istio 治理的处理提出抗议” 。相信很多小伙伴看了以后，针对 Istio、微服务都有一丝疑虑，接下来我们用灵魂拷问的方式，来分析相关的问题。本文仅代表作者个人观点。
拷问 1：为啥要用微服务？

文章插图

编辑搜图
请点击输入图片描述
在谈微服务靠谱靠谱之前，我们先说说微服务本质是啥？咱们不妖魔化概念，捡干的说。
微服务的“微”，是小的意思。比传统单体应用小。怎么把大的单体应用变小？拆呗。
至于怎么拆，这是门学问，后面说。
为什么拆？
容器时代之前，拆微服务的不多，拆主要是为了方便组件独立开发、升级，balabala........
在容器云时代，有的应用比较大，不拆就上不了容器云。
上不了容器云有什么问题么？
没啥问题。如果在虚拟机甚至物理机上运行，你没觉得他慢，弹性能力差，你没觉得它有问题，那就是没问题，就别拆。Oracle RAC这样式的，也没法拆，也上不了容器云（起码段时间内）。
结论：上容器云的本质目的，是由于你想利用容器云让你的应用运行弹性扩展能力增强、开发迭代速度加快，所以要把应用往容器云上挪。有的轻量级的 web 应用好挪，不用拆就能怼上去。有的应用大，直接上不去，向上就得拆，就费用微服务。
有人问，为啥非要上容器云？没有非要。当年虚拟化大流行的年代，谁没规定非要上 vSphere 啊。很简单：根据自己的需要。
拷问 2：咋听说上了微服务后，运维难度增加？微服务靠谱不？首先，微服务这个概念，一定程度上被妖魔化、被玩坏了。好像微服务站在了一切“传统”应用的对立面，就像当面满清入关，必须剃所有应用的头发一样，所有应用必须要拆，拆的越碎越好。
现在市面上使用最多的微服务，还是以 SpringBoot 为开发框架的 SpringCloud 系，这是实时。
但是，我要说的是：SpringCloud 架构确实比较复杂，而且是代码侵入式的。大魏曾经上过一门微服务迁移的课（红帽内部一周的课），每天基本做的事情，就是改源码。需要使用 SpringCloud 的哪个治理组件，就得把对应的代码（主要是 annotation 方式）加进去，把配置参数也加进去。大幅增加了应用开发人员的工作量。
而造成这个问题的关键点在于：SpringCloud 是站在七层（应用），解决 4-7 层的所有问题（应用之间调度，RBAC 等）。码农工作量不大才怪。
如果有要说微服务靠谱不这个话题。首先来说，SpringBoot 挺靠谱的。SpringCloud 框架庞杂，如果业务没那么多治理需求的话，建议挑少量的治理组件上，别一下都怼上。
拷问 3：微服务或者说云原生的应用开发框架，只能选 SpringBoot？不是。
SpringBoot 是目前很流行的开发框架，起源是要解决 EJB 太重的问题，但还是重。
而微服务和云原生要求什么？pod 启动快、占用资源少。
这方便，Quarkus 有它的优势，尤其是云原生。
IDC 对比过 SpringBoot 和 Quarkus 的性能，后者高不少。但 Quarkus 也有其限制，用其所长。
详细内容参考我之前写的文章：关于云原生应用的思考
拷问 4：Istio 被吹了好几年了，它咋出来的？靠谱不？如拷问 2 所述：SpringCloud 要求码农通过代码实现从 4-7 层的所有逻辑，显然太累，灵活性也差。这时候 google 和 IBM 出于要简化这件事的目的，联手推出了基于 K8S 的微服务治理框架 Istio（技术细节不赘述，想了解可以买我的书《OpenShift 在企业中的实践》）。
也就是说，像 RBAC，服务注册中心、微服务之间调用路由等啥啥问题，Istio 都干了。这确实是架构上的创新。
那为啥 Istio 现在生产案例不多呢？其实也有案例，国内外都有，但和 SpringCloud 相比，还是少。
从技术角度看：