亚洲视频二区_亚洲欧洲日本天天堂在线观看_日韩一区二区在线观看_中文字幕不卡一区

最近看到一個新聞，說是內容是 “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 相比，還是少。

從技術角度看：

1. Istio 是個迭代的比兔子跑的還快的開源項目。小版本迭代甚至以周記。Istio 迭代后，有時候架構，API 都會有一些變化，平滑升級不順暢（例如直接從 Istio 1.1 升級到 1.2）。
2. Istio 本身就是個微服務的框架，組件太多，自身運行也比較消耗資源，比如 mixer 組件。Istio 到了 1.5，引入了 Istiod，架構有所精簡。具體的效果大魏還沒測試。
3. Istio 采用 sidecar 的方式，在每個 pod 中業務容器旁邊塞一個代理。pod 流量出棧入棧都會先經過這個代理。這個代理增加了應用訪問的時間。如果說個時間的話，不少于 10ms。當應用規模大、微服務之間相互調用太多時，這個延遲就會有指數級增長。
4. 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。

這種方法的大致步驟是：

1. 在 pom.xml 中注銷 SpringCloud 組件的的 Maven 依賴，如：Eureka 。
2. 刪除代碼中 SpringCloud 的 annotation，如 @EnableDiscoveryClient
3. 集中的配置文件回到各個項目中
4. 用 jar 包構建鏡像。也就應用容器化，可以使用 OCP 的 S2I builderimage。
5. 創建 ConfigMap 用于注入環境變量。
6. 在 OCP 上部署應用，部署的時候，記住要注入 sidecar。

轉載來源：OSChin.net原文標題：靈魂拷問 x6：微服務到底靠譜不？
原文鏈接：https://my.oschina.net/u/4567873/blog/4400010

?