最近看到一个新闻,说是内容是 “IBM、甲骨文、CNCF 就谷歌对 Istio 治理的处理提出抗议”。相信很多小伙伴看了以后,针对 Istio、微服务都有一丝疑虑,接下来我们用灵魂拷问的方式,来分析相关的问题。本文仅代表作者个人观点。
编辑搜图
请点击输入图片描述
在谈微服务靠谱靠谱之前,我们先说说微服务本质是啥?咱们不妖魔化概念,捡干的说。
微服务的“微”,是小的意思。比传统单体应用小。怎么把大的单体应用变小?拆呗。
至于怎么拆,这是门学问,后面说。
为什么拆?
容器时代之前,拆微服务的不多,拆主要是为了方便组件独立开发、升级,balabala........
在容器云时代,有的应用比较大,不拆就上不了容器云。
上不了容器云有什么问题么?
没啥问题。如果在虚拟机甚至物理机上运行,你没觉得他慢,弹性能力差,你没觉得它有问题,那就是没问题,就别拆。Oracle RAC这样式的,也没法拆,也上不了容器云(起码段时间内)。
结论:上容器云的本质目的,是由于你想利用容器云让你的应用运行弹性扩展能力增强、开发迭代速度加快,所以要把应用往容器云上挪。有的轻量级的 web 应用好挪,不用拆就能怼上去。有的应用大,直接上不去,向上就得拆,就费用微服务。
有人问,为啥非要上容器云?没有非要。当年虚拟化大流行的年代,谁没规定非要上 vSphere 啊。很简单:根据自己的需要。
首先,微服务这个概念,一定程度上被妖魔化、被玩坏了。好像微服务站在了一切“传统”应用的对立面,就像当面满清入关,必须剃所有应用的头发一样,所有应用必须要拆,拆的越碎越好。
现在市面上使用最多的微服务,还是以 SpringBoot 为开发框架的 SpringCloud 系,这是实时。
但是,我要说的是:SpringCloud 架构确实比较复杂,而且是代码侵入式的。大魏曾经上过一门微服务迁移的课(红帽内部一周的课),每天基本做的事情,就是改源码。需要使用 SpringCloud 的哪个治理组件,就得把对应的代码(主要是 annotation 方式 )加进去,把配置参数也加进去。大幅增加了应用开发人员的工作量。
而造成这个问题的关键点在于:SpringCloud 是站在七层(应用),解决 4-7 层的所有问题(应用之间调度,RBAC 等)。码农工作量不大才怪。
如果有要说微服务靠谱不这个话题。首先来说,SpringBoot 挺靠谱的。SpringCloud 框架庞杂,如果业务没那么多治理需求的话,建议挑少量的治理组件上,别一下都怼上。
不是。
SpringBoot 是目前很流行的开发框架,起源是要解决 EJB 太重的问题,但还是重。
而微服务和云原生要求什么?pod 启动快、占用资源少。
这方便,Quarkus 有它的优势,尤其是云原生。
IDC 对比过 SpringBoot 和 Quarkus 的性能,后者高不少。但 Quarkus 也有其限制,用其所长。
详细内容参考我之前写的文章:关于云原生应用的思考
如拷问 2 所述:SpringCloud 要求码农通过代码实现从 4-7 层的所有逻辑,显然太累,灵活性也差。这时候 google 和 IBM 出于要简化这件事的目的,联手推出了基于 K8S 的微服务治理框架 Istio(技术细节不赘述,想了解可以买我的书《OpenShift 在企业中的实践》)。
也就是说,像 RBAC,服务注册中心、微服务之间调用路由等啥啥问题,Istio 都干了。这确实是架构上的创新。
那为啥 Istio 现在生产案例不多呢?其实也有案例,国内外都有,但和 SpringCloud 相比,还是少。
从技术角度看:
那么,Istio 到底靠谱不。从长远看,靠谱。因为毕竟 Istio 是基于 K8S 的框架对微服务的架构性创新,随着 Istio 版本的迭代,性能和稳定性的提升,案例会越来越多。
这有两种方法:
(1)将所有 SpringCloud 和应用一起容器化,然后挪到 OCP 上。
这种方法的好处是:不用改 SpringCloud 框架,上来基本就能用。缺点是让让本就复杂的 SpringCloud 更加复杂。
(2)将 SpringCloud 迁移的时候,按照 K8S 的特点,对组件进行改造。K8S 层有的就用 K8S 的。如下表所示。
这种需要点工作量改造需需要点工作量,好处是后续微服务架构就能一定晨读上调用 K8S,效率高一些,后续运维也会方便。比如写应用的时候,直接用 K8S的 service name。
编辑搜图
请点击输入图片描述
编辑搜图
请点击输入图片描述
这种方法比拷问 5 中的第二种稍微激进一些,但未来是这个方向。这种做法的好处是业务逻辑用 Spring Boot 实现,其他功能实现都交给交给 Openshift+Istio。
这种方法的大致步骤是:
转载来源:OSChin.net原文标题:灵魂拷问 x6:微服务到底靠谱不?
原文链接:https://my.oschina.net/u/4567873/blog/4400010