最近看到一個(gè)新聞，說是內(nèi)容是 “IBM、甲骨文、CNCF 就谷歌對(duì) Istio 治理的處理提出抗議”。相信很多小伙伴看了以后，針對(duì) Istio、微服務(wù)都有一絲疑慮，接下來(lái)我們用靈魂拷問的方式，來(lái)分析相關(guān)的問題。本文僅代表作者個(gè)人觀點(diǎn)。
拷問 1：為啥要用微服務(wù)？
編輯搜圖
請(qǐng)點(diǎn)擊輸入圖片描述
在談微服務(wù)靠譜靠譜之前，我們先說說微服務(wù)本質(zhì)是啥？咱們不妖魔化概念，撿干的說。
微服務(wù)的“微”，是小的意思。比傳統(tǒng)單體應(yīng)用小。怎么把大的單體應(yīng)用變小？拆唄。
至于怎么拆，這是門學(xué)問，后面說。
為什么拆？
容器時(shí)代之前，拆微服務(wù)的不多，拆主要是為了方便組件獨(dú)立開發(fā)、升級(jí)，balabala........
在容器云時(shí)代，有的應(yīng)用比較大，不拆就上不了容器云。
上不了容器云有什么問題么？
沒啥問題。如果在虛擬機(jī)甚至物理機(jī)上運(yùn)行，你沒覺得他慢，彈性能力差，你沒覺得它有問題，那就是沒問題，就別拆。Oracle RAC這樣式的，也沒法拆，也上不了容器云（起碼段時(shí)間內(nèi)）。
結(jié)論：上容器云的本質(zhì)目的，是由于你想利用容器云讓你的應(yīng)用運(yùn)行彈性擴(kuò)展能力增強(qiáng)、開發(fā)迭代速度加快，所以要把應(yīng)用往容器云上挪。有的輕量級(jí)的 web 應(yīng)用好挪，不用拆就能懟上去。有的應(yīng)用大，直接上不去，向上就得拆，就費(fèi)用微服務(wù)。
有人問，為啥非要上容器云？沒有非要。當(dāng)年虛擬化大流行的年代，誰(shuí)沒規(guī)定非要上 vSphere 啊。很簡(jiǎn)單：根據(jù)自己的需要。
拷問 2：咋聽說上了微服務(wù)后，運(yùn)維難度增加？微服務(wù)靠譜不？
首先，微服務(wù)這個(gè)概念，一定程度上被妖魔化、被玩壞了。好像微服務(wù)站在了一切“傳統(tǒng)”應(yīng)用的對(duì)立面，就像當(dāng)面滿清入關(guān)，必須剃所有應(yīng)用的頭發(fā)一樣，所有應(yīng)用必須要拆，拆的越碎越好。
現(xiàn)在市面上使用最多的微服務(wù)，還是以 SpringBoot 為開發(fā)框架的 SpringCloud 系，這是實(shí)時(shí)。
但是，我要說的是：SpringCloud 架構(gòu)確實(shí)比較復(fù)雜，而且是代碼侵入式的。大魏曾經(jīng)上過一門微服務(wù)遷移的課（紅帽內(nèi)部一周的課），每天基本做的事情，就是改源碼。需要使用 SpringCloud 的哪個(gè)治理組件，就得把對(duì)應(yīng)的代碼（主要是 annotation 方式 ）加進(jìn)去，把配置參數(shù)也加進(jìn)去。大幅增加了應(yīng)用開發(fā)人員的工作量。
而造成這個(gè)問題的關(guān)鍵點(diǎn)在于：SpringCloud 是站在七層（應(yīng)用），解決 4-7 層的所有問題（應(yīng)用之間調(diào)度，RBAC 等）。碼農(nóng)工作量不大才怪。
如果有要說微服務(wù)靠譜不這個(gè)話題。首先來(lái)說，SpringBoot 挺靠譜的。SpringCloud 框架龐雜，如果業(yè)務(wù)沒那么多治理需求的話，建議挑少量的治理組件上，別一下都懟上。
拷問 3：微服務(wù)或者說云原生的應(yīng)用開發(fā)框架，只能選 SpringBoot？
不是。
SpringBoot 是目前很流行的開發(fā)框架，起源是要解決 EJB 太重的問題，但還是重。
而微服務(wù)和云原生要求什么？pod 啟動(dòng)快、占用資源少。
這方便，Quarkus 有它的優(yōu)勢(shì)，尤其是云原生。
IDC 對(duì)比過 SpringBoot 和 Quarkus 的性能，后者高不少。但 Quarkus 也有其限制，用其所長(zhǎng)。
詳細(xì)內(nèi)容參考我之前寫的文章：關(guān)于云原生應(yīng)用的思考
拷問 4：Istio 被吹了好幾年了，它咋出來(lái)的？靠譜不？
如拷問 2 所述：SpringCloud 要求碼農(nóng)通過代碼實(shí)現(xiàn)從 4-7 層的所有邏輯，顯然太累，靈活性也差。這時(shí)候 google 和 IBM 出于要簡(jiǎn)化這件事的目的，聯(lián)手推出了基于 K8S 的微服務(wù)治理框架 Istio（技術(shù)細(xì)節(jié)不贅述，想了解可以買我的書《OpenShift 在企業(yè)中的實(shí)踐》）。
也就是說，像 RBAC，服務(wù)注冊(cè)中心、微服務(wù)之間調(diào)用路由等啥啥問題，Istio 都干了。這確實(shí)是架構(gòu)上的創(chuàng)新。
那為啥 Istio 現(xiàn)在生產(chǎn)案例不多呢？其實(shí)也有案例，國(guó)內(nèi)外都有，但和 SpringCloud 相比，還是少。
從技術(shù)角度看：
- Istio 是個(gè)迭代的比兔子跑的還快的開源項(xiàng)目。小版本迭代甚至以周記。Istio 迭代后，有時(shí)候架構(gòu)，API 都會(huì)有一些變化，平滑升級(jí)不順暢（例如直接從 Istio 1.1 升級(jí)到 1.2）。
- Istio 本身就是個(gè)微服務(wù)的框架，組件太多，自身運(yùn)行也比較消耗資源，比如 mixer 組件。Istio 到了 1.5，引入了 Istiod，架構(gòu)有所精簡(jiǎn)。具體的效果大魏還沒測(cè)試。
- Istio 采用 sidecar 的方式，在每個(gè) pod 中業(yè)務(wù)容器旁邊塞一個(gè)代理。pod 流量出棧入棧都會(huì)先經(jīng)過這個(gè)代理。這個(gè)代理增加了應(yīng)用訪問的時(shí)間。如果說個(gè)時(shí)間的話，不少于 10ms。當(dāng)應(yīng)用規(guī)模大、微服務(wù)之間相互調(diào)用太多時(shí)，這個(gè)延遲就會(huì)有指數(shù)級(jí)增長(zhǎng)。
- Istio 本身還是站在運(yùn)維角度去考慮問題的，運(yùn)維人員覺得不錯(cuò)，但 Istio 沒有和應(yīng)用開發(fā)框架有深度的集成。但寫應(yīng)用的是開發(fā)人員，他們對(duì)這些未必關(guān)心。SpringCloud 想對(duì)接受的廣，本質(zhì)上是因?yàn)?SringBoot 的開發(fā)友好型。
那么，Istio 到底靠譜不。從長(zhǎng)遠(yuǎn)看，靠譜。因?yàn)楫吘?Istio 是基于 K8S 的框架對(duì)微服務(wù)的架構(gòu)性創(chuàng)新，隨著 Istio 版本的迭代，性能和穩(wěn)定性的提升，案例會(huì)越來(lái)越多。
拷問 5：我的應(yīng)用現(xiàn)在 vm 上使用的 SpringCloud，怎么向 K8S/OCP(OpenShift) 遷移？
這有兩種方法：
（1）將所有 SpringCloud 和應(yīng)用一起容器化，然后挪到 OCP 上。
這種方法的好處是：不用改 SpringCloud 框架，上來(lái)基本就能用。缺點(diǎn)是讓讓本就復(fù)雜的 SpringCloud 更加復(fù)雜。
（2）將 SpringCloud 遷移的時(shí)候，按照 K8S 的特點(diǎn)，對(duì)組件進(jìn)行改造。K8S 層有的就用 K8S 的。如下表所示。
這種需要點(diǎn)工作量改造需需要點(diǎn)工作量，好處是后續(xù)微服務(wù)架構(gòu)就能一定晨讀上調(diào)用 K8S，效率高一些，后續(xù)運(yùn)維也會(huì)方便。比如寫應(yīng)用的時(shí)候，直接用 K8S的 service name。
編輯搜圖
請(qǐng)點(diǎn)擊輸入圖片描述
編輯搜圖
請(qǐng)點(diǎn)擊輸入圖片描述
拷問 6：我現(xiàn)在用的是 K8S+SpringCloud，怎么向 OCP+Istio 遷移？
這種方法比拷問 5 中的第二種稍微激進(jìn)一些，但未來(lái)是這個(gè)方向。這種做法的好處是業(yè)務(wù)邏輯用 Spring Boot 實(shí)現(xiàn)，其他功能實(shí)現(xiàn)都交給交給 Openshift+Istio。
這種方法的大致步驟是：
- 在 pom.xml 中注銷 SpringCloud 組件的的 Maven 依賴，如：Eureka 。
- 刪除代碼中 SpringCloud 的 annotation，如 @EnableDiscoveryClient
- 集中的配置文件回到各個(gè)項(xiàng)目中
- 用 jar 包構(gòu)建鏡像。也就應(yīng)用容器化，可以使用 OCP 的 S2I builderimage。
- 創(chuàng)建 ConfigMap 用于注入環(huán)境變量。
- 在 OCP 上部署應(yīng)用，部署的時(shí)候，記住要注入 sidecar。
轉(zhuǎn)載來(lái)源：OSChin.net原文標(biāo)題：靈魂拷問 x6：微服務(wù)到底靠譜不？
原文鏈接：https://my.oschina.net/u/4567873/blog/4400010
?
