原文作者：李同剛
原文連結：
https://developer.aliyun.com/article/738878?spm=a2c6h.12873581.0.0.3a2b115ex69Iht&groupCode=cloudnative 更多雲原生技術資訊可關注 阿裡巴巴雲原生技術圈為什麼有這個主題？
記得2018年參加上海KubCon大會時，演講人現場對國内生産使用Kubernetes情況的調查，現場舉手的寥寥無幾。時至今日，參加2019“MVP閉門大會”和“雲栖大會”，感受到“雲原生”無處不在。那麼當容器、容器編排遇到傳統微服務架構，會擦出怎樣的火花，這其中有哪些坑？人類對科學的追求總是義無反顧的，進化到雲原生時代，我們的機遇和挑戰是什麼？
希望在這個場合一起探讨下，沒有對錯，隻有适合與否。關鍵是當開始有溝通，才可能繼續往前走。
這個系列文章采用總分總的方式寫，第一篇主要探讨整體架構，後面文章探讨各部分更具體的技術方案，最後總結。
探讨整體架構
讓我們從一張圖開始第一篇正式内容，這是一個可能的最小化服務化架構：
這是一個傳統架構和容器技術混合的架構，在全面介紹之前，我們先分别看下各自的發展史，“知道從哪兒來，方知道我們往哪兒去”。
從傳統部署時代到容器部署時代
下面這張圖從運維角度描述了，應用從傳統部署時代如何發展到容器部署時代。也折射出企業上雲的發展過程。
在國内，阿裡雲吹響了企業上雲的号角。第一階段，是IT基礎設施雲化，包括虛拟機、網絡等上雲，降低企業運維成本、提升彈性伸縮能力。第二階段，是核心架構雲化，包括阿裡雲資料庫、阿裡雲微服務引擎 ( Microservice Engine, 簡稱：MSE )、全局事務服務GTS等，Kubernetes或許也算。第二階段的更新版可能是全面擁抱Cloud Native，随着有狀态應用和無狀态應用全面擁抱Kubernetes，我們可以猜測走向了面向Kubernetes程式設計時代，開發人員不必關心微服務治理的各種技術棧和開發語言（諸如：Golang、Java等），寫好業務代碼，定義好雲原生開放應用模型（OAM），釋出上線即可，應用将變得更輕量、接入成本更低、疊代更靈活。
IT行業發展是如此迅速，卻又是如此必然。類比下，程式設計語言從彙編、C++、Java到新型語言Golang，無不是從複雜到易用的過程。易用、輕量貫穿整個行業的發展脈絡，是以我們有理由相信這一天的到來，盡管過程比較曲折，Istio如今還不盡如人意。
那些年，我們折騰過的微服務架構
下圖來源于螞蟻金服@卓與（ 一個帥又專業的小夥:) ）的一次SOFAMesh分享。基本代表了，傳統微服務架構Dubbo、SOFABoot、Spring Cloud等微服務架構核心能力和應用之間的關系。這類微服務架構提供“胖用戶端”內建到應用，這個小胖每次更新都會影響到應用，也增加了中間件開發團隊和業務團隊溝通、協調成本，因為耦合太緊了。讓我們寄希望于Cloud Native來解吧！
混合架構
熟悉Kubernetes的同學知道，他有幾個對于微服務架構來講重要能力：
容器編排能力
架起了容器鏡像和硬體資源的橋梁，通過yarml聲明輕松釋出“可執行”程式，配合Liveness 和 Readiness可以做到不停機滾動釋出，這都減輕了微服務營運成本。
服務發現能力
Kubernetes可以使用DNS（這是一個較早的基于服務端的服務發現模式）名稱暴露一個應用叢集的服務位址。Kubernetes還可以用負載均衡，把流量配置設定到Pod，進而使服務更穩定。這部分看着是否和“胖用戶端”的服務發現有點兒像。
在Service Mesh沒有完全落地之前，我們是否可以結合Kubernetes上述能力和傳統微服務架構能力，各自發揮所長，組成一個混合架構呢，于是有了開篇第一張大圖。
本篇總結
我們探讨了容器技術和傳統微服務架構特點，并且嘗試結合各自優勢，組成一個混合架構。
後面我們就具體的技術領域做探讨和可能的坑。
“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”