微服務部署 Docker 和 Kubernetes<十六> 譯

    迄今爲止，咱們已經討論了微服務的多個方面，覆蓋組織敏捷性，設計依賴思想，域驅動設計和承諾理論。而後咱們深刻到實現中，用三個流行的java框架來開發：spring boot、Dropwizard和WildFly Swarm。咱們能夠經過暴露和消耗 Rest 端點，使用環境配置選項、打包爲一個可執行 jar 文件、公開度量等方式來輕鬆地利用強大的開箱即用功能。這些概念都圍繞着一個單實例的實例進行。可是當您須要管理依賴項、得到一致啓動或關閉、進行健康檢查、負載平衡您的微服務時，會發生什麼？在本章中，咱們將討論那些高層次概念，以便更多地瞭解部署微服務的挑戰，無論它是如何使用局域網的。

    當咱們開始將應用程序和服務從 microservices 中分離出來時，咱們最終會經過定義來實現更多移動片斷：咱們擁有更多服務、更多二進制文件、更多配置、更多的交互點等等。咱們傳統上處理 java 應用程序，經過構建二進制文件(jars、wars 和 ears)，將它們放在某處(共享磁盤、磁盤空間和工件存儲庫)、打開票證，但願操做團隊按照咱們的意圖將它們部署到應用服務器中，並使用正確的權限和環境變量和配置。咱們還將應用服務器部署到集羣中，這些服務器具備冗餘硬件、負載平衡器和共享磁盤，並儘可能避免故障。咱們可能已經在紅外結構周圍創建了一些自動化，支持這類工具，好比 Chef 或 Ansible 等偉大工具，可是不知何故部署應用程序仍然會充滿錯誤、配置漂移和意外行爲。

    經過這個模型，咱們作了不少但願，在當前環境中迅速崩潰，在規模上保持良好的狀態。應用服務器是否配置在dev/qa/prod中，就像咱們的機器上同樣嗎？若是不是，咱們是否徹底捕獲了須要作的更改並向業務人員表達？咱們的任何更改是否會影響其餘應用程序，也能夠運行在同一個應用服務器上？運行時組件是否與操做系統、jvm 和相關依賴關係徹底相同，與咱們開發機器上的關係徹底相同？運行應用程序的jvm很是複雜，咱們應用程序的實現細節是如何配置、調優和運行的，所以跨環境中的這些變體可能會形成嚴重破壞。當您開始交付microservices時，您是否在傳統服務器上分別運行它們？過程隔離夠嗎？若是一個jvm狂暴而且接管了超過100%的cpu，會發生什麼呢？仍是網絡io？仍是共用磁盤？若是主機崩潰時運行的全部服務都會怎樣呢？你的應用程序是爲了適應這個嗎？當咱們把應用程序分紅小塊時，這些問題就變得更加突出了。

Immutable Delivery

不可變傳遞概念有助於咱們對這些問題的緣由。使用不可變的交付方式，咱們嘗試將移動塊的數量做爲構建過程的一部分減小到預備映像中。對於測試而言，想象一下在構建過程當中，您能夠經過操做系統、jvm的預約版本、任何應用程序以及全部配置來輸出徹底的預備映像？而後，您能夠在一個環境中部署此工具，測試它，並將其沿傳遞管道遷移到生產，而沒必要擔憂是否已一致配置環境或應用程序。若是須要對應用程序進行更改，則從新運行此管道線，該管道將生成應用程序的新不變映像，而後進行滾動升級以交付它。若是它不工做，您能夠經過部署前一個映像回滾。別再擔憂了。關於配置或環境漂移，或者在回滾中是否正確恢復了這些內容。

聽起來不錯但咱們怎麼作到？可執行jar是一個方面，讓咱們在那裏的方式，但仍然還須要其餘的支持。jvm 是咱們的 microservice 的一個實現細節，因此咱們如何捆綁 jvm ？JVMs 是用本地代碼編寫的，而且具備本地 os 級別依賴關係，咱們須要打包。咱們還須要配置、環境變量、權限、文件目錄以及其餘必須打包的東西。全部這些細節都不能在單個可執行 jar 中捕獲。其餘二進制格式如虛擬機(Vm)映像能夠正確封裝這些細節。然而，對於每一個可能具備不一樣包裝需求的microservice(jvm？NodeJS？屬性文件？私鑰？)，咱們能夠輕鬆地看到虛擬機映像的爆炸式增加以及語言運行時的運行狀態。若是您將基礎設施做爲代碼自動化，而且可使用適當暴露的api來訪問基礎設施，那麼您就能夠作到這一點。事實上，做爲自動化交付管道的一部分構建 vm 正是.net了實現這種不可變交付級別的緣由。可是vm變得難以管理、修補和更改。每一個虛擬機都會使用所需設備驅動程序、操做系統和管理工具來實現整個機器的運行。

    咱們還能夠探索哪些其餘輕量級的包裝和鏡像格式？

    下篇再續

原文：

做者源碼：https://github.com/redhat-developer/microservices-by-example-source

有什麼討論的內容，能夠加我微信公衆號：