在阿裡雲容器服務上開發基于Docker的Spring Cloud微服務應用

本文為阿裡雲容器服務spring cloud應用開發系列文章的第一篇。

一、在阿裡雲容器服務上開發spring cloud微服務應用(本文)

單體應用通常指在一個程式中滿足多個業務或技術領域的需求，不同的需求領域内化為子產品。假定我們要開發一個web應用，通常的mvc模式可以滿足要求。針對不同領域有不少代碼生成工具可以快生成代碼架構，從0到1建立一個應用非常容易。放在一個應用裡處理所有的事情的好處是非常大的，比如程式的調試相對容易，執行效率高。

單體的應用在規模變大後其前述好處會很快衰減。随着業務的增長，需求的調整和變更，應用内部會以子產品為基礎進行重構，增加和删減、改變子產品的能力。應用逐漸超越開發人員所能掌控的範圍，代碼死角開始出現，重構變得困難。變更經常是牽一發而動全身。針對任何一個子產品的擴容或更新都是對整個應用的所有子產品的擴容和更新。程式對外界的依賴越來越複雜，自動化測試的覆寫率低。

如何避免單體應用的問題引入了微服務的概念。每個服務隻處理一件事情，應用由多個服務構成。服務之間通過web協定進行通信，例如http/json。代碼要易于抛棄：出問題的代碼可以更容易地重寫。運作的服務也要易于抛棄，更新時用一個新的服務執行個體替代舊的執行個體。

把單體應用分解為一些列微服務，開發團隊也可以進行“重構”，每個小團隊負責一個服務，維護和學習成本下降了。由于服務間通過接口進行連接配接，每個服務的内部實作機制可以根據領域選擇更合适的技術，混合程式設計是很自然的事情，試錯的成本降低、試錯的頻率加快，進而意味着創新的速度可以提高。

如此美好的微服務也不是“銀彈”。它隻是說了“微”是好的，但沒有說出如何變“微”。如果對業務領域的了解不全，對需求的把控不準，服務可能隻是小的單體應用而已。

另外的問題來源于分布式計算。單體服務中兩個子產品的調用是高效、可靠的，而兩個服務之間的網絡通信是低效且不可靠的。分布式計算中的很多經典問題無法繞開，比如服務的可用性、資料的一緻性等。

服務執行個體數目的不斷變化，資料流量的波動導緻監控和日志分析的複雜度大大提升。現在開源的監控和日志方案很多，但如何搭建并定制一套自己的方案并不是一件容易的事。

當然我們不能因噎廢食，如果有一個平台已經能夠提供其中大部分非功能需求，比如高可用、監控和日志等，那麼在其上建構和營運一個微服務應用很容易了。阿裡雲的容器服務就是這樣一個平台。

微服務的實作需要有高度标準化的傳遞技術來支撐，容器技術很好地滿足了這個需求。利用容器技術把應用及其依賴做成一個标準的鏡像，從開發到測試到生産環境都用同樣的鏡像，devops把開發和運維中間的鴻溝彌補起來。容器技術正逐漸成為微服務和devops領域的最佳實踐，成為這些領域創新的基石。

在本系列文章中，我們探讨在阿裡雲的容器服務上，如何利用spring cloud來構造一個微服務應用。

示例模拟的場景是企業内部應用服務化，服務之間通過api互相通路。foo服務和bar服務是兩類基本服務，允許内網其他服務通過api通路，但不對外網提供服務。foobar對外提供服務，在處理時需要調用foo服務和bar服務。

服務發現機制由discovery-server提供，基于eureka實作。由于discovery-server的業務無關性，開發人員可以直接使用docker鏡像。

foobar服務通過注冊到智能應用路由gateway服務上對外提供服務，gateway基于zuul，其代碼業務無關，開發人員可以直接使用其docker鏡像，但由于zuul是通過配置檔案來描述不同的服務對應的url通路模式，是以在實際使用中需要改變鏡像中的配置檔案，或者通過挂載volume實作配置檔案的共享和修改。

foo, bar和foobar的代碼中都包含了eureka和ribbon client，實作了向eureka的自注冊和查詢eureka的能力，ribbon實作了用戶端的負載均衡。本示例中沒有引入hystrix。

服務間的邏輯架構如下圖所示。

每個服務在運作時都可以根據負載水準彈性擴充，每個服務可能由多個運作中的執行個體構成。所有服務執行個體在啟動時自動注冊到eureka server，服務之間的發現也是通過eureka server擷取執行個體資訊，并由ribbon client自動判斷，選取一個執行個體進行通路。在這個過程中沒有用到集中式的負載均衡，而是通過用戶端發現和負載均衡。

在下一篇文章中我們會讨論如何編譯和部署這個應用。

轉載自：https://yq.aliyun.com/articles/57265?spm=5176.100244.teamconlist.3.lgvr5v