一篇文章即可了解「你的公司到底需不需要微服務」

最近一段時間，好像人人都對微服務推崇不已，彷彿它可以拯救你那龐大而老舊的資料庫，解決你目前項目中存在的所有問題，但是任何技術都不是銀彈，它解決不了所有的問題。本文將嘗試帶領你剖析，什麼條件下，你的團隊需要微服務架構。

也許你正在經歷下面的開發流程

試想一下，你目前正在開發一款軟體來對抗你的競爭對手，當你把產品的核心需求梳理完畢後，整個項目進入開發階段，你會手動創建一個新項目，也許你會用到 Maven來構建你的項目並管理項目所需的 jar包，然後整個項目將以商業邏輯為核心，它由定義服務、域對象和事件各模塊來完成，各種適配器圍繞核心與外部交互。適配器包括資料庫訪問組件、生成和 consume 信息的消息組件，以及提供 API 或者 UI 訪問支持的 Web 模塊。應用仍然以整體來打包和部署，然後部署在 Tomcat 或者 Jetty 這樣的應用伺服器。

也許這是你每天必備的工作，但同時，你也因此踏入了單體架構的地獄。幾年之後，當這個項目迭代了多個版本後，你會發現應用變得龐大而複雜，你的開發團隊也將飽受折磨，苦苦掙扎于敏捷開發和交付，甚至修復 bug 要遠遠比開發新功能所付出的時間還要多，這樣的前提還是你沒有產出新的 bug。試想一下，如果你目前正在維護一個十萬行的 JSP文件，你的心裡是什麼感受。

微服務帶來的好處

有很多公司，比如 NetFlix和 Amazon等，都通過微服務的方式極大的緩解了以上的問題，其本質就是將一個巨大的單體應用拆分成很多個互相連接的微服務，這樣如果一個服務掛掉後不會對整個應用產生致命的影響。簡單來說，實施微服務，整個公司的架構會有如下的好處：

每項微服務相對較小，易於開發者理解其業務邏輯，Web容器啟動速度更快，提高開發者生產效率並可加快部署速度；

每項服務皆可獨立的開發和部署，並且部署簡單，大大簡化頻繁部署新服務版本的流程；

改善故障隔離，就如之前所說，一個微服務掛掉後，整體應用的其他功能不受影響，利於後期維護；

微服務架構模式使得每個服務獨立擴展，可以根據每個服務的規模來部署滿足需求的實例；

既然微服務有這麼多好處，那是不是所有公司都可以直接用微服務來解決業務上的問題呢？之前說過，沒有任何一項技術是完全的陽春白雪。

實施微服務的先決條件

針對微服務實施的先決條件，之前 Phil Cal?ado有過一段很精彩的論述，他說，「當你決定採用微服務，你將經歷從單一應用到一個複雜系統的轉變過程。在這個系統里，你會遇到很多無法預測的行為，因為團隊和服務在持續地發生變化，它們被創建、被修改，然後被銷毀。系統的快速變更能力為你的組織帶來了巨大的好處，不過你需要確保你有一些安全護欄，否則你的交付會因為無窮無盡的變更而駐足不前。」

Phil Cal?ado總結了，如果你的團隊要實施微服務，要滿足以下的先決條件。

快速配置：具備在短時間內配置好一台伺服器的能力；

基本的監控：生產環境中，很多輕度耦合的服務在一起協作容易出現問題，而這些問題在測試環境中難以被發現，所以我們需要一個有效的監控機制來快速地檢測這些問題；

快速部署：因為需要管理的服務太多，所以需要儘快地部署它們，不管是在測試環境還是在生產環境；

同時，他在實踐中也總結出，易分配的儲存、標準的 RPC等因素也是決定一個微服務成敗的先決條件，所以，Phil Cal?ado列出了關於微服務先決條件的完整清單如下（按照優先順序從上到下）：

計算資源的快速分配

基本的監控

快速部署

易於分配的存儲

易於訪問的外圍

認證和授權

標準化的 RPC

所以，一個團隊如果想成功實施微服務還是有不少的問題有待解決，如果有一位業內頂級的專家給你指導，手把手教你在微服務實施中如何避免各種坑，那你一定會節省很多時間。

如果你對微服務感興趣，不妨關注一下 7月 8日 -9日，在深圳·華僑城洲際酒店舉辦的 ArchSummit全球架構師峰會深度培訓上，我們很榮幸地邀請到了天弘基金（餘額寶）移動平台技術總監 & 首席架構師——李鑫老師，他在大規模分散式應用及治理、中間件雲化及服務化（PaaS）、APM監控、基礎開發平台等領域都有著非常豐富的經驗，如果你想了解微服務的治理模型，並想知道如何通過「監控」及「管控」這兩大能力的構建來綜合解決微服務的現實治理需求，那麼本次培訓將會是你最好的選擇。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！