最近一段時間，好像人人都對微服務推崇不已，彷彿它可以拯救你那龐大而老舊的數據庫，解決你目前項目中存在的所有問題，但是任何技術都不是銀彈，它解決不了所有的問題。本文將嘗試帶領你剖析，什麼條件下，你的團隊需要微服務架構。
也許你正在經歷下面的開發流程
試想一下，你目前正在開發一款軟件來對抗你的競爭對手，當你把產品的核心需求梳理完畢後，整個項目進入開發階段，你會手動創建一個新項目，也許你會用到 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
所以，一個團隊如果想成功實施微服務還是有不少的問題有待解決，如果有一位業內頂級的專家給你指導，手把手教你在微服務實施中如何避免各種坑，那你一定會節省很多時間。
現在掃描下方二維碼進行報名
可享 8折優惠，立省 960元
閱讀更多 InfoQ 的文章
