在軟件開發領域不存在銀彈，當用一項新的技術或新的架構時一定要明白其背后的原理，確保把合適的技術應用在合適的項目上，而不是盲目跟風。

單體應用伸縮性差，而且隨著應用規模的擴大，業務邏輯和開發部署過程都變得極其復雜。牽一發而動全身，任何一個微小的改動都有可能影響整個應用，新技術的更新換代對于單體應用來說幾乎是個不可能的任務。

相比單體應用，微服務靈活自由，伸縮性強，近年來深受軟件開發者的熱捧。不過，微服務雖然沒有了單體應用的某些局限，但卻對開發運維和整個組織提出了更高的要求。在采用微服務架構之前開發者要先想清楚自己的項目是否適合采用微服務架構，以及是否有足夠的能力運維一個微服務生態系統。

微服務概念的提出者Martin Fowler其實在很早之前就說明了使用微服務需要具備的三個核心能力，分別是服務器的快速擴容、監控和應用的快速部署。下面是具體介紹。

硬件資源是否能夠快速到位

為了避免資源競爭和服務間的相互影響，微服務一般是部署在單獨的硬件資源上。當有新的微服務加入系統，或者需要對微服務進行伸縮時，必需能足夠快地為其準備相應的硬件資源。如果使用了云服務，在獲取新資源時會相對容易一些。但在沒有云服務的情況下，那么至少需要有一個自動化或者半自動化的系統能夠滿足快速分配資源的需求。

是否具備了微服務監控能力

微服務生態系統可能會很龐大，服務間相互依賴，個體微服務的可用性會影響整個系統的可用性。對微服務進行監控可以及時地發現微服務的運行狀況，如果有些服務出現故障（可能有些在測試階段沒有被測出來的缺陷進入了生產環境），需要及時回滾到之前的穩定版本，避免對系統的整體可用性造成影響。

是否具有快速的開發部署流程

微服務變化很快，一個微服務在一天之內可能需要部署多次，因此需要一個快速的開發、部署以及測試流程?？梢栽谡麄€流程中引入部署管道，部署管道規定了一系列嚴格的自動化部署過程，可以加快部署的速度。

微服務系統通常涉及多個團隊之間的合作，除了開發團隊之間的合作之外，還有開發團隊和運維團隊之間的合作。運維團隊需要保證開發團隊能夠活得足夠的資源，當發生問題時，運維團隊能夠快速向開發團隊暴露問題，開發團隊能夠及時地解決問題。DevOps是開發和運維之間的粘合劑，可以促進團隊之間的合作。

微服務系統比我們想象的要復雜得多。微服務給我們帶來了諸多好處，同時也對我們提出了更高的要求。必要的時候，我們需要通過調整組織結構來更好地支持微服務系統的發展。所以在轉向微服務架構時，需要先考慮好這些問題，并想清楚微服務是否真的適合自己。