編譯丨千山

51CTO讀者成長計(jì)劃社群招募，咨詢小助手（微信號(hào)：CTOjishuzhan）

長年從事IT咨詢工作，Jan Kammerath看到了很多公司的IT基礎(chǔ)設(shè)施和系統(tǒng)架構(gòu)。在過去十年里，他觀察到這樣一個(gè)現(xiàn)象：Kubernetes和Apache Kafka變得非常普遍和流行，但對一些企業(yè)來說，部署效果卻并不那么盡如人意。

魔鬼藏在細(xì)節(jié)里，別人都在用不代表你也適合。

1、一切是怎么開始的

有一天，某家中型軟件公司的CEO打電話找我咨詢。

這家公司的SaaS產(chǎn)品運(yùn)行良好，商業(yè)化也很成功。在過去幾十年的發(fā)展中，已經(jīng)從面向Windows的桌面軟件產(chǎn)品成功過渡為一個(gè)具有微服務(wù)架構(gòu)的成熟SaaS產(chǎn)品。

這位CEO本人在20世紀(jì)90年代中期編寫了最初的產(chǎn)品。隨著產(chǎn)品的升級(jí)迭代，他不再參與具體的開發(fā)工作。

一般來說，管理層可能不太了解開發(fā)團(tuán)隊(duì)的具體事宜，但當(dāng)事情的發(fā)展似乎要出現(xiàn)偏差時(shí)，他們通常會(huì)有某種直覺。在多數(shù)情況下，他們只是想讓我檢查一下，并希望得到一些來自外部的肯定，來確保他們的IT基礎(chǔ)設(shè)施和開發(fā)流程都很好。接到這位CEO的電話時(shí)，我也是這么想的。不過事情顯然沒有那么簡單。

公司業(yè)務(wù)的利潤率很好，運(yùn)營成本也在可接受范圍內(nèi)，真正令CEO頭疼的是，“我們的可用性只有87%，我們的SLA是95%，我已經(jīng)為下一個(gè)財(cái)年的運(yùn)營增加了50萬歐元的預(yù)算?！?/p>

盡管到目前為止他們還沒收到任何客戶投訴，但是這位老板依舊對于他們的服務(wù)質(zhì)量和不斷上升的運(yùn)營成本深表擔(dān)憂。對此，我非常理解：50萬歐的額外投入對于這種體量的公司來說并非小事。

即使在2019年，87%的可用性也非常糟糕。而且95%的SLA依舊意味著總共兩周的中斷。通常來說，SaaS的SLA在一年中大多在97-99%左右。97%仍然相當(dāng)于11天的總停機(jī)時(shí)間。

2、為什么選擇Kubernetes和Kafka

擔(dān)任顧問的角色時(shí)，下結(jié)論之前必須收集足夠的信息。

我了解到：他們使用了一個(gè)托管的git存儲(chǔ)庫和一個(gè)大型存儲(chǔ)庫主機(jī)，并使用Jenkins作為CI/CD管道，將每個(gè)微服務(wù)部署到Kubernetes集群中。服務(wù)總線，微服務(wù)之間的通信，是通過Kafka完成的。

在現(xiàn)代化進(jìn)程中，曾經(jīng)有一個(gè)顧問來為他們的IT基礎(chǔ)設(shè)施起草整體的現(xiàn)代化和遷移方案，包括在Kubernetes上運(yùn)行重構(gòu)應(yīng)用程序，并通過Kafka傳遞消息。如今這個(gè)顧問早就離職了，現(xiàn)在的運(yùn)營和工程團(tuán)隊(duì)對于這種設(shè)置并不感冒，還有人直接問我有沒有更簡潔的替代方案。

在我查看了所有的項(xiàng)目文檔之后，發(fā)現(xiàn)最初使用Kubernetes和Kafka的主要理由是“與云無關(guān)”。

與云無關(guān)是指一種云設(shè)計(jì)策略，其中應(yīng)用程序、工具和服務(wù)旨在以混合模式在多個(gè)云平臺(tái)之間或本地和云之間無縫遷移，而不會(huì)中斷服務(wù)。這種策略的一些原則是支持獨(dú)立于底層操作系統(tǒng)的無縫可移植性，確保遷移中工作負(fù)載的有限中斷，并限制應(yīng)用程序停機(jī)的風(fēng)險(xiǎn)，同時(shí)提高成本效率。

公司可以輕松地以簡化和直接的方式構(gòu)建與云無關(guān)的應(yīng)用程序。這是因?yàn)?Kubernetes 創(chuàng)建了一種跨不同公共云和私有云環(huán)境管理和運(yùn)行應(yīng)用程序的標(biāo)準(zhǔn)方法。

在那段時(shí)間里，有人認(rèn)為最好“獨(dú)立于任何云提供商”。而且我認(rèn)為風(fēng)險(xiǎn)是CEO腦海中縈繞的一個(gè)念頭。

3、如何解決“與云無關(guān)”策略的弊端

雖然與云無關(guān)的方法為組織提供了一些好處，讓相關(guān)的公司組織在與云無關(guān)時(shí)可以避免被鎖定在單個(gè)供應(yīng)商中，但這也可能是其工程團(tuán)隊(duì)的劣勢。

比如，一個(gè)云提供商提供了對貴司的應(yīng)用程序很重要的關(guān)鍵功能，那么如果其他云提供商沒有此功能，則可能無法在與云無關(guān)的方法中使用它。無法使用云提供商的創(chuàng)新服務(wù)可能會(huì)減慢團(tuán)隊(duì)的速度并使競爭對手處于優(yōu)勢地位。

另外一個(gè)潛在缺點(diǎn)就是處理意外的數(shù)據(jù)傳輸成本。眾所周知，這些成本很難預(yù)測和理解。對于許多組織來說，構(gòu)建多個(gè)云提供商可能不經(jīng)濟(jì)。可替代方案是什么呢？在這個(gè)案例中，我給出的建議是：無服務(wù)器。

考慮到他們擁有的吞吐量和資源利用率，他們幾乎不會(huì)達(dá)到AWS任何無服務(wù)器產(chǎn)品的服務(wù)限制。在AWS SNS上每秒不會(huì)超過200條消息，更不用說達(dá)到AWS SQS隊(duì)列限制了。他們用Kafka所能做的一切沒有什么是SNS或SQS所不能做到的。

由于他們已經(jīng)在AWS上運(yùn)行了Kubernetes和Kafka，他們可以很容易地遷移到無服務(wù)器產(chǎn)品(Lambda、API Gateway、SQS、SNS)，而且他們的基礎(chǔ)設(shè)施賬單也有很好的成本降低潛力。很明顯，他們的主要問題是Kubernetes集群的運(yùn)行占用了大量的時(shí)間，而且沒有云基礎(chǔ)設(shè)施本身的成本。

針對這些情況，我做了一個(gè)演示，解釋了團(tuán)隊(duì)將如何遷移到無服務(wù)器產(chǎn)品。最重要的是，我提出了一個(gè)風(fēng)險(xiǎn)緩解路線圖，我的藍(lán)圖甚至提供了一個(gè)完整的“災(zāi)難撤退到本地部署”。退回到本地部署的選擇聽起來很荒謬，但在大多數(shù)情況下可以緩解擔(dān)憂。

畢竟，我能夠說服團(tuán)隊(duì)和管理層逐步轉(zhuǎn)向無服務(wù)器。我還說服他們用CI/CD管道產(chǎn)品取代他們的Jenkins，他們已經(jīng)為他們的存儲(chǔ)庫主機(jī)支付了費(fèi)用。我同意他們的意見，之后我會(huì)繼續(xù)觀察事情進(jìn)展如何。

4、99.99%的可用性，成本降低約40%

大約在我拜訪的7個(gè)月后，他們問我是否可以對他們迄今為止所構(gòu)建以及遷移的東西做一個(gè)架構(gòu)回顧。

我又去了他們的辦公室，基本全天都在看架構(gòu)圖。老實(shí)說，并沒有什么神奇之處：帶有API gateway和Lambda的微服務(wù)，帶有SNS的中央服務(wù)總線，以及帶有SQS的幾個(gè)扇形架構(gòu)。許多DynamoDB表和S3桶。

從技術(shù)的角度來看，他們的產(chǎn)品沒有很高的復(fù)雜性。他們的產(chǎn)品優(yōu)勢在于，他們與他們所在的特定行業(yè)的現(xiàn)有客戶生態(tài)系統(tǒng)緊密集成。他們還將客戶高度專業(yè)化的業(yè)務(wù)流程完全自動(dòng)化，并開發(fā)了許多令人印象深刻的功能。他們擁有的最“復(fù)雜”的系統(tǒng)是關(guān)系數(shù)據(jù)庫和搜索引擎。

由于大部分基礎(chǔ)設(shè)施運(yùn)營已經(jīng)外包給了亞馬遜，因此可用性的顯著提高也就不足為奇了。與此同時(shí)，他們已經(jīng)通過云賬單削減了成本，因?yàn)樗麄儚腒ubernets遷移的服務(wù)將不再永久運(yùn)行，而是只在需要時(shí)運(yùn)行。

5、這不是Kubernetes和Kafka的錯(cuò)，但是……

Kubernetes和Kafka在技術(shù)上沒有任何問題，但是Kubernetes和Kafka有可能成為一個(gè)經(jīng)濟(jì)問題。

雖然從技術(shù)上講，這是一個(gè)非常好的解決方案，但很多企業(yè)既沒有人力也沒有財(cái)力來運(yùn)營Kubernetes和Kafka。當(dāng)企業(yè)，更具體地說是內(nèi)部人員，最初決定使用k8s和Kafka時(shí)，他們沒有將TCO(總擁有成本)與其他替代方案(如AWS、谷歌Cloud或Azure上的無服務(wù)器)進(jìn)行基準(zhǔn)測試。

運(yùn)行Kubernetes集群需要人力、時(shí)間和預(yù)算。在我參與的大多數(shù)業(yè)務(wù)案例中，Kubernetes在經(jīng)濟(jì)性方面總是落后于無服務(wù)器，甚至是負(fù)載均衡器與多az部署的虛擬機(jī)。

無論你的技能有多好，如果Kubernetes集群的TCO是第二備選的2 - 4倍，你就會(huì)陷入麻煩。隨著越來越多的公司轉(zhuǎn)向FaaS(功能即服務(wù))，所需要做的只是盡職調(diào)查或技術(shù)審計(jì)，你將需要解釋為什么要運(yùn)行Kubernetes集群。

當(dāng)你的管理層看到其他公司的標(biāo)桿時(shí)，“每個(gè)人都這么做”是一個(gè)相當(dāng)站不住腳的理由。

結(jié)果是你的老板可能會(huì)因?yàn)镵ubernetes集群或昂貴的Kafka環(huán)境而責(zé)怪你。我的建議是：積極地對Kubernetes和/或Kafka集群的總擁有成本進(jìn)行基準(zhǔn)測試（AWS、谷歌Cloud、Azure或IBM/Red Hat的無服務(wù)器產(chǎn)品都有該測試）。評(píng)估你是否需要Kubernetes和/或Kafka，以及為什么沒有合理的替代方案。

當(dāng)你有Kafka和Kubernetes的經(jīng)驗(yàn)時(shí)，它肯定會(huì)在你的簡歷上看起來很好，當(dāng)你把它們?nèi)拥揭贿叄?jié)省了50萬歐元的成本時(shí)，它會(huì)看起來更好。你的雇主花在超重基礎(chǔ)設(shè)施和系統(tǒng)上的每一分錢，都不能花在你的下一次加薪上。比起運(yùn)行Kubernetes集群的輝煌，你更有可能因?yàn)橄鳒p成本、提高服務(wù)質(zhì)量和縮短上市時(shí)間而獲得回報(bào)。

原文鏈接：https://medium.com/@jankammerath/how-kubernetes-and-kafka-will-get-you-fired-a6dccbd36c77