微服務的部署與釋出：部署微服務将面臨的挑戰
當單塊架構被劃分成微服務之後，随着微服務數量的增多，毫無疑問，将會面臨比單塊架構更複雜的問題。
部署微服務将面臨的問題
部署微服務将會面臨以下問題。
1.運維負擔
對傳統的單塊架構系統來說，産品通常隻有一個釋出包，更新、部署系統往往隻需要部署這個釋出包即可。現在，面臨着這麼多的微服務，顯然運維的負擔要比之前更重了。對于運維工程師來說，部署的服務呈指數上升，傳統的手工部署方式往往已經不能适應日益增長的服務運維需求。
⒉服務間的依賴
在一個微服務結構中，你更容易遇到的錯誤是來自依賴的問題。在微服務架構系統中，某些業務功能需要幾個微服務協同才能完成，這些服務之間難免存在一定的依賴關系。特别是以某種方式更新某個服務的API時，同時也會影響其他服務，造成某些服務的不可用。例如，在天氣預報系統中，天氣預報微服務是依賴于天氣資料API微服務及城市資料API微服務的，隻要這兩個資料API微服務其中一個不可用，則會導緻整個天氣預報微服務不可用。是以在更新服務時，需要先确定哪些服務需要更新，而後評估更新對其他服務的影響是什麼。
3.更多的監控
每個微服務往往需要設定單獨的監控，這意味着更多的監控。而且每個微服務可能使用不同的技術或語言，依靠不同的機器或容器，使用其特有的版本控制，這也大大增加了監控的複雜性。
4.更頻繁的釋出
每個微服務都需要單獨部署，這就意味着需要更多的服務釋出。微服務的顆粒度相對較小，修改和釋出也較為容易，是以釋出也會相對更加頻繁。這是微服務的優點，但同時也是實施微服務所要解決的難題。
5.更複雜的測試
微服務化之後，服務可以獨立開發和測試，團隊或成員之間可以并行快跑，這極大提高了系統的研發效率，但也給測試工作帶來了挑戰。除了驗證各個獨立微服務之外，我們還需要考慮通過具有分布式特性的微服務架構檢查全部關鍵性事務的執行路徑。由于微服務的目标之一在于實作快速變更，是以我們必須更加關注服務的依賴性，以及性能、可通路性、可靠性和彈性等非功能性要求。
如何解決上述問題
針對上面的部署和釋出的問題，一般采取如下的解決思路。
1.自動化運維
微服務顯著增加了開發團隊的運維和工具負擔。每個服務都需要一個部署管道、一個監控系統、自動報警、輪流電話值班等。在這種情況下，采用自動化運維手段，可以有效提升運維的效率。
微服務需要大量的基礎設施用于開發和部署，是以要使用一個自動化運維平台。Kubernetes ,Swarm、Mesos、Docker及其他類似産品可以提供很大的幫助。
2.處理服務間的依賴關系
服務越多，服務間的依賴關系就越複雜。其中解決其複雜關系的一個基本原則是:永遠隻有不同層級的單向依賴，即上層依賴下層，高層服務可以依賴低層服務，同層服務間不互相依賴。這樣就能讓系統有一個清晰的依賴關系，而且這樣的話，單向依賴就永遠不可能形成環狀。如果出現了同層服務間依賴，就說明服務分層出現了問題，此時需要抽象出一個更高層次的服務或者提升其中一個服務的層次。
3.日志收集
由于微服務的數量衆多，每個服務都有自己的日志，那麼通過這些散落的日志來檢視服務的狀态将會變成一個難題。針對微服務的日志，我們傾向于将所有的微服務的日志進行收集，盡量統一到一個平台中，這樣就能在同一個平台中監控所有微服務的狀态。
日志收集方式也盡量做到統一。由于很多設計裡對于業務日志、容器日志、主控端日志等采用不同的agent，這是一個不好的設計方式，因為agent也是需要管理的，引入太多agent隻會給自己增加不必要的管理成本。
在日志收集方面的方案有Splunk、Logstash、Flume、Fluentd等。本書後續章節也會對微服務的日志管理展開詳細的讨論。
4.監控和告警
從功能上來說，服務的監控可以分為兩種類型，一種是對主機的監控，另一種是對服務的監控。
對于服務的監控，是指在不知道服務具體運作的情況下去檢查這個服務本身是否可用，以及在它出了故障以後如何進行故障的恢複。這種監控方式在容器和非容器上差異性比較小，但是與具體使用的技術棧或平台會有比較大的關聯性。例如，如果使用JConsole工具來監控程式的性能，顯然這裡的程式隻能是Java程式。對于主機的監控，是指我們需要去了解這個伺服器内部的運作狀态，如CPU使用率是否爆滿，磁盤占用一段時間是否出現異常。對于主機監控主要作用有兩點，一種是出現嚴重故障的時候，我們要對發生故障的現場進行回溯，另一種是我們通過監控資料能夠去預測—些可能發生的問題。
當監控到異常時，監控軟體最好能自動做出一些處置機制。例如，在內建伺服器中，當檢測到送出的代碼有問題時，內建伺服器會自動将部署的版本回溯到上一個可用的版本，以保證現場部署的服務始終可用。
當監控軟體檢測到系統超過門檻值時，應該要發送告警資訊給運維人員。常見的告警方式有短信、郵件、閃光燈、音響喇叭等。
5.微服務的釋出
由于同一個微服務可能會被釋出到多個主機上進行水準擴充，這就要求不同的主機之間部署的是相同的軟體。同時，微服務能夠獨立于其他微服務釋出或者取消釋出，在部署時，微服務之間的功能不會産生互相影響。
一種比較好的方式是把微服務打包成鏡像，這樣就保證了不同主機之間能夠使用相同的鏡像。
同時，由于鏡像中包含了服務的配置檔案和環境，這樣，就可以盡可能地避免主機環境對軟體部署産生的影響。
考慮使用Docker容器，這将會使建構、釋出、啟動微服務變得十分快捷。
通過Kubernetes能夠進一步擴充Docker 的能力，能夠從單個Linux主機擴充到Linux叢集，支援多主機，管理容器的位置，提供服務發現等功能，這些都是微服務需求的重要特性。是以，利用Kubernetes管理微服務和容器的釋出，是一個非常有力的方案。
6.API版本控制
版本控制應當适用于任何API，對微服務也一樣。如果有某些改動打破了API的格式，那麼就應當針對該改動單獨釋出另外一個版本。無論是公共接口還是其他内部服務使用的接口，在我們不清楚誰在使用這些接口的前提下，必須要保證向下相容，或者至少要給使用者足夠的時間去适應。