最近看到一个新闻，说是内容是 “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 相比，还是少。
从技术角度看：
Istio 是个迭代的比兔子跑的还快的开源项目。小版本迭代甚至以周记。Istio 迭代后，有时候架构，API 都会有一些变化，平滑升级不顺畅（例如直接从 Istio 1.1 升级到 1.2）。
Istio 本身就是个微服务的框架，组件太多，自身运行也比较消耗资源，比如 mixer 组件。Istio 到了 1.5，引入了 Istiod，架构有所精简。具体的效果大魏还没测试。
Istio 采用 sidecar 的方式，在每个 pod 中业务容器旁边塞一个代理。pod 流量出栈入栈都会先经过这个代理。这个代理增加了应用访问的时间。如果说个时间的话，不少于 10ms。当应用规模大、微服务之间相互调用太多时，这个延迟就会有指数级增长。
Istio 本身还是站在运维角度去考虑问题的，运维人员觉得不错，但 Istio 没有和应用开发框架有深度的集成。但写应用的是开发人员，他们对这些未必关心。SpringCloud 想对接受的广，本质上是因为 SringBoot 的开发友好型。
那么，Istio 到底靠谱不。从长远看，靠谱。因为毕竟 Istio 是基于 K8S 的框架对微服务的架构性创新，随着 Istio 版本的迭代，性能和稳定性的提升，案例会越来越多。
拷问 5：我的应用现在 vm 上使用的 SpringCloud，怎么向 K8S/OCP(OpenShift) 迁移？
这有两种方法：
（1）将所有 SpringCloud 和应用一起容器化，然后挪到 OCP 上。
这种方法的好处是：不用改 SpringCloud 框架，上来基本就能用。缺点是让让本就复杂的 SpringCloud 更加复杂。
（2）将 SpringCloud 迁移的时候，按照 K8S 的特点，对组件进行改造。K8S 层有的就用 K8S 的。如下表所示。
这种需要点工作量改造需需要点工作量，好处是后续微服务架构就能一定晨读上调用 K8S，效率高一些，后续运维也会方便。比如写应用的时候，直接用 K8S的 service name。
拷问 6：我现在用的是 K8S+SpringCloud，怎么向 OCP+Istio 迁移？
这种方法比拷问 5 中的第二种稍微激进一些，但未来是这个方向。这种做法的好处是业务逻辑用 Spring Boot 实现，其他功能实现都交给交给 Openshift+Istio。
这种方法的大致步骤是：
在 pom.xml 中注销 SpringCloud 组件的的 Maven 依赖，如：Eureka 。
删除代码中 SpringCloud 的 annotation，如 @EnableDiscoveryClient
集中的配置文件回到各个项目中
用 jar 包构建镜像。也就应用容器化，可以使用 OCP 的 S2I builderimage。
创建 ConfigMap 用于注入环境变量。
在 OCP 上部署应用，部署的时候，记住要注入 sidecar。
