以前，我們邀請幾位嘉賓討論了他們在開發(fā)微服務(wù)時遇到的挑戰(zhàn)，比如Fred George或Dustin Huptas和Andreas Schmidt。近日，Usman Ismail參加了一場小組會議，討論了微服務(wù)持續(xù)交付面臨的挑戰(zhàn)，并決定隨后詳述其中的部分重點內(nèi)容。他首先討論了微服務(wù)其中一個基本原則的缺點，那允許大型團隊通過快速原型和迭代以一種更加敏捷的方式推進（軟件）開發(fā)：

不過，微服務(wù)顯著增加了開發(fā)團隊的運維和工具負擔(dān)。每個服務(wù)都需要一個部署管道、一個監(jiān)控系統(tǒng)、自動報警、輪流電話值班，等等。對于大型團隊，所有這些負擔(dān)都可以視為提升特性開發(fā)效率的合理代價，是創(chuàng)建這些系統(tǒng)值得付出的努力。不過，在小型團隊中，如果同一批人負責(zé)所有的服務(wù)，那么無論如何，為多個項目復(fù)制管道都是開銷上的浪費。

接下來考慮的是運維負擔(dān)。在Usman看來，使用微服務(wù)或單體架構(gòu)，如果推出了一個服務(wù)或組件的不良版本，就需要回滾系統(tǒng)，而且如果遇到資源限制，則（常常）可以橫向擴展。不過，使用微服務(wù)，你需要更多的監(jiān)控和自動化才能檢測出哪些服務(wù)需要回滾，并確定回滾一個服務(wù)對其他依賴它的服務(wù)產(chǎn)生什么影響，等等。

如果你有自動報警系統(tǒng)（你真應(yīng)該有一個），那么你需要把報警信息發(fā)給服務(wù)所有者，并為多個服務(wù)維護一個電話值班時間表。在小型組織中，負責(zé)不同服務(wù)的人群之間會有很大的重疊。這就是說，我們必須針對這些服務(wù)協(xié)調(diào)時間表，以確保同一個人不會被許多服務(wù)鉤住，讓人們在輪流電話值班之外得到一些喘息。由于這些以及上一節(jié)中提到的原因，最好是開始引入多個微服務(wù)的開銷之前有一個單體架構(gòu)，并把所有的運維工作安排妥當(dāng)。

然后當(dāng)然是微服務(wù)一個基本特點——一個在傳統(tǒng)單體應(yīng)用中可能不會提到或者很少提到的特點：分布式。這引發(fā)了一個古老的問題，就是在分布式環(huán)境中調(diào)試，我們過去已經(jīng)提到過許多次，在微服務(wù)這個術(shù)語被創(chuàng)造出來以前。原先，Joyent首席技術(shù)官Bryan Cantrill探討過在生產(chǎn)環(huán)境中調(diào)試微服務(wù)。Usman認(rèn)為，沒有一個集中式的微服務(wù)日志是一種致命的缺陷：

而且，在規(guī)模比較大的情況下，有一個單獨的監(jiān)控系統(tǒng)（比如datadog、grahite）和一個單獨的日志聚合系統(tǒng)（比如ELK、loggly或Splunk）是不可行的。在這種規(guī)模下，可視化指標(biāo)和日志數(shù)據(jù)是一個大數(shù)據(jù)問題，最好在一個地方解決。

對于小組會議的最后一個重點，Usman提到了部署協(xié)調(diào)和版本管理。文章認(rèn)為，微服務(wù)和單體應(yīng)用的其中一個重大差別是前者是一棵服務(wù)依賴樹，而后者是一個圖：

例如，在單體模型中，一個典型的服務(wù)棧可能包含一個“Web組件組合（web array）”，它調(diào)用一個緩存層、數(shù)據(jù)庫層，可能還有一些獨立服務(wù)，比如身份驗證，等等。在微服務(wù)模型中，你會有一個連通圖或者服務(wù)網(wǎng)絡(luò)，每個服務(wù)都依賴于幾個其他的服務(wù)。有一點很重要，就是要確保這個圖是一個有向無環(huán)圖（DAG），否則你會陷入依賴地獄，可能還會遇到分布式堆棧溢出錯誤。

有趣的是，Usman的文章接下來總結(jié)了嘉賓們提出的一些指導(dǎo)原則：

參加小組會議的嘉賓，沒有哪個人對他們的微服務(wù)系統(tǒng)十分滿意，也就無法為如何構(gòu)建這樣一個系統(tǒng)提出任何類似指南的東西，不過，我們確實提出了一些經(jīng)驗法則或者一般的指導(dǎo)原則，包括下列這些。

這些原則可以總結(jié)為：

微服務(wù)需要大量的基礎(chǔ)設(shè)施用于開發(fā)和部署，因此要使用一個平臺。“Kubernetes、Swarm、Mesos以及其他類似產(chǎn)品可以提供很大的幫助，但你仍然需要使監(jiān)控、調(diào)試、“連續(xù)管道（continuous pipeline）”和服務(wù)發(fā)現(xiàn)機制一體化。” 為了實現(xiàn)可再現(xiàn)、可靠的自動化，不要通過人工過程定義系統(tǒng)的任何東西。“任何東西都必須通過代碼定義，可測試，可再現(xiàn)。例如，服務(wù)器/虛擬機的配置應(yīng)該使用docker-machine、puppet、ansible等進行編排。 開發(fā)或使用集中式監(jiān)控、日志和報警。“單體服務(wù)就像一個深受喜愛的寵物，你知道它所有的怪癖和習(xí)慣，而微服務(wù)就像牲畜；你要它們?nèi)慷疾畈欢嘁粯樱⒆鳛橐粋€普通的畜群進行管理，而不是一個個體。” 務(wù)必確保向后向前兼容。 將大型微服務(wù)部署可視化為一個網(wǎng)絡(luò)。“監(jiān)控和管理一個大型微服務(wù)部署同管理一個網(wǎng)絡(luò)系統(tǒng)十分類似。”

所有的建議都是基于來自各類公司的嘉賓們的集體經(jīng)驗。那些建議一直隨著時間演變，將來可能會隨著經(jīng)驗的日益豐富而繼續(xù)演變。在某種程度上，Usman最后的評論附和了Vijay Alagarasan去年在演講“7種微服務(wù)反模式”中所講的內(nèi)容：

[微服務(wù)]并不是解決構(gòu)建和運行大規(guī)模分布式軟件基本問題的魔彈。微服務(wù)架構(gòu)迫使你更謹(jǐn)慎地遵循最佳實踐和自動化工作流。本次討論的一個重要結(jié)論是，除非你愿意將大量的時間和資源從特性開發(fā)工作轉(zhuǎn)到構(gòu)建和維護一個服務(wù)框架上，否則最好避免進入微服務(wù)的世界。不過，如果你能夠投入時間構(gòu)建一個很棒的服務(wù)框架和工作流，那么你將完成重大轉(zhuǎn)變，成為一個更敏捷、更有生產(chǎn)力的組織。

我們總是在尋求更深入的微服務(wù)經(jīng)驗，有好的經(jīng)驗，也有不好的經(jīng)驗，因此，或許你想自己對Usman的工作或討論作出評判。

查看英文原文：Challenges of Microservices Deployments