本篇是《使用Spring Boot和Docker構建微服務架構》系列的第四篇，本篇我們我們將添加一些額外的服務/容器，并且更新容器，采用Docker Compose以及使用HAProxy容器進行負載均衡。原文作者為3Pillar環球旗下美國Adbanced技術集團的總監Dan Greene，Dan有十八年的軟件設計和開發經驗，包括在電子商務、B2B集成、空間分析、SOA架構、大數據以及云計算等領域的軟件產品架構經驗，他是AWS認證解決方案架構師，在3Pillar之前先后就職于Oracle、ChoicePoint和Booz Allen Hamilton。Dan畢業于喬治●華盛頓大學，他也是一個父親、業余木工愛好者，還參加過包括國際障礙大賽這樣的障礙賽跑。現在我們對于微服務和Docker有了扎實的了解，啟動了一個MongoDB容器和Spring Boot微服務容器并且借助于容器的link機制（參考我們的Git版本庫第四部分開始部分）實現了它們之間的相互通訊。為了完成我們最初的用例，我們需要兩個微服務——分別是“missions”和“rewards”。我將開始這個話題并按照與我們之前構建employee微服務相同的方式來構建這兩個微服務，可以參考Git版本庫第四部分的第一步來獲得這兩個微服務容器。現在如果我們執行docker ps，我們將看到如下的信息，其中的一些列為了簡潔被移掉了：CONTAINER ID IMAGE PORTS NAMES86bd9bc19917 microservicedemo/employee 0.0.0.0:32779->8080/tcp employee1c694e248c0a microservicedemo/reward 0.0.0.0:32775->8080/tcp rewardc3b5c56ff3f9 microservicedemo/mission 0.0.0.0:32774->8080/tcp mission48647d735188 mongo 0.0.0.0:32771->27017/tcp mongodb
更新鏡像這都是很簡單的，但是沒有太大的作用，因為此時沒有一個微服務可以在簡單的數據CRUD功能之外帶來任何直接的價值。讓我們開始對一些代碼的更改進行分層，以提供更多的價值和功能。我們會對某個微服務做出一些改變，然后處理如何更新鏡像，了解對于容器的版本控制。由于員工通過完成任務來獲得積分，我們需要追蹤他們的任務完成情況、積分總計（獲得和活躍的）以及獎勵兌換。我們將添加一些額外的類到Employee模型中——這些不是頂層的業務對象，所以它們不會有它們自己的微服務，但是將會在Employee對象中提供上下文內容。一旦這些變化做出了（參見Git版本庫第四部分第二步），將會有一些結構性的改變，需要在整個軟件棧中同步，更新鏡像的步驟如下：● 重新編譯源代碼gradle build
● 重新構建鏡像docker build -t microservicedemo/employee .
最后將會看到一些如下的消息：Removing intermediate container 5ca297c19885 Successfully build 088558247
● 現在我們需要刪除舊容器，替換為新的：docker stop employeedocker rm employeedocker run -P -d --name employee --link mongodb microservicedemo/employee
需要注意的重要事項就是在運行容器內的代碼是不會更新的，容器和微服務的另外一個核心原則是容器內部的代碼和配置是不可變的。換句話說，你不用更新容器，只需要替換它。這對于一些容器的使用案例會造成一些問題，比如使用容器來操作數據庫或者其它的持久化資源。使用Docker Compose來編排容器像我一樣，如果你在本系列文章之間有其他的工作要做，如何確保所有的各種命令行參數都可以來連接這些容器，可能有點令人沮喪。編排這一隊容器就是Docker Compose（以前被成為Fig）的目的。在Yaml配置文件中定義你的一組容器，并且管理這些容器的運行時配置。在很多方面，可以把Docker Compose想象成為一個編排者，確保“正運行”的容器有著正確的選項和配置。我們將通過命令行參數為我們的應用創建一個這樣的編排者來做所有管理想做的事情。docker-compose.yml：employee:build: employeeports:- "8080"links:- mongodbreward:build: rewardports:- "8080"links:- mongodbmission:build: missionports:- "8080"links:- mongodbmongodb:image: mongo
接著在命令行上敲入：docker-compose up -d
然后整個一隊容器都將會啟動，非常方便！許多Docker命令在Docker-Compose上都有類似的命令，如果我們運行"docker-compose ps
"，我們會看到：Name Command State Ports
git_employee_1 java -Dspring.data.mongodb ... Up 0.0.0.0:32789->8080/tcpgit_mission_1 java -Dspring.data.mongodb ... Up 0.0.0.0:32785->8080/tcpgit_mongodb_1 /entrypoint.sh mongod Up 27017/tcpgit_reward_1 java -Dspring.data.mongodb ... Up 0.0.0.0:32784->8080/tcp
容器的動態伸縮和負載均衡不過上述這些還不是Docker Compose可以做的所有工作，如果你運行“docker-compose scale [compose container name]=3
”，，將會創建多個容器實例。比如運行“docker-compose scale employee=3
”，接著運行“docker-compose ps
”，將會看到：Name Command State Ports
git_employee_1 java -Dspring.data.mongodb ... Up 0.0.0.0:32789->8080/tcpgit_employee_2 java -Dspring.data.mongodb ... Up 0.0.0.0:32791->8080/tcpgit_employee_3 java -Dspring.data.mongodb ... Up 0.0.0.0:32790->8080/tcpgit_mission_1 java -Dspring.data.mongodb ... Up 0.0.0.0:32785->8080/tcpgit_mongodb_1 /entrypoint.sh mongod Up 27017/tcpgit_reward_1 java -Dspring.data.mongodb ... Up 0.0.0.0:32784->8080/tcp
我們的employee容器現在有了三個實例！Docker Compse記得你設置的數量，所以下次運行的時候，將會啟動三個employee容器實例，就我個人而言，我認為這個應該在docker-compose.yml文件中設置，但是其實不是的。希望你開始看到一個問題如何發展的。我們應該如何構建一個針對終端用戶的事實上使用微服務的應用呢？因為容器的端口變了，并且在一個Docker集群服務器環境中（比如Docker Swarm），宿主機的IP地址也會改變。有一些先進的解決方案（Kubernetes和AWS的ECS），但是現在我們將尋找一個相對簡單的選項，將采用一個非常容易的方法來對容器實例做負載均衡。Tutum是一家構造多重云容器組織能力的公司，已經給Docker社區提交了一個HAProxy的擴展插件，這個擴展插件會基于連接的容器自動配置其自身。讓我們為多個employee容器實例添加一個負載均衡器，我們將其添加到docker-compose.yml文件中：…ha_employee:image: tutum/haproxylinks:- employeeports:- "8080:80"
接著我們運行“docker-compose up -d
”，將會下載缺失的鏡像并且啟動容器。現在我們可以再次在特定的端口（8080）運行測試，這次將會對于所有運行的employee容器進行負載均衡。接著，我們可以在192.168.99.100:8080上敲擊employee服務集群，默認情況下將會輪循這三個實例。易如反掌！HAProxy的Docker容器還有許多額外的特性和功能點，我建議可以從https://github.com/tutumcloud/haproxy獲得更多的信息。HAProxy對于一個特定容器的多個實例的負載均衡處理地非常巧妙，是單容器環境的理想選擇。然而，我們沒有這樣的環境，那咋辦？我們可以啟動多個HAProxy實例來處理容器集群，在宿主機的不同端口上轉發每一個HAProxy容器端口，所以我們的employee服務放在了8080端口，mission服務放在8081端口，reward服務放在8082端口（參考Git版本庫第四部分第三步）。如果我們來到生產環境，我們可以利用Nginx來創建反向代理，將所有的服務請求轉發到一個單獨的IP地址和端口上（通過URL路徑/employee/和/reward/路由到相應的容器）。或者我們可以使用一個更加健壯的服務發現路由，比如這兒的利用etcd和一些讓人印象深刻的Docker元數據腳本和模板引擎，來自于Jason Wilder的Docker-gen系統（https://hub.docker.com/r/jwilder/docker-gen/），以及大量的額外的自我管理的服務發現的解決方案。我們目前將會保留這個簡單的HAProxy解決方案，因為它給與了我們一個對于如何管理容器集群的扎實的理解。這是一個結束本系列的好地方。我可以說還有有許多額外的領域還沒有涉及到，包括：● 構建一個前端的容器，或者一個移動APP容器● 包含后端的數據批處理過程● 動態分級的容器集群來處理消息隊列的條目● 將服務從Java/Spring Boot遷移到Scala/Akka/Play● 建立持續集成● 構造自己的鏡像Repository或者使用容器Repository服務（Google或者Docker Hub）● 評估容器管理系統比如AWS的ECS或者Kubernetes原文鏈接：BUILDING A MICROSERVICE ARCHITECTURE WITH SPRING BOOT AND DOCKER, PART IV（翻譯：胡震）