最近看到一个新闻，说是内容是 “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。
作者本人最近也参与了开源中国的 高手问答 活动，想对云原生和微服务等方面有更多了解的，可查看本期内容： 如何构建企业级云原生应用
