前言
在傳統的開發中，我們通常是將所有的功能打包在一起，然後統一部署在一個JEE容器（Tomcat，JBoss，WebLogic）裡，包含了 DO/DAO，Service，UI等所有邏輯。如下圖所示：
這種開發方式雖然操作簡單，代碼重用率高，沒有分佈式的管理和調用消耗，但是由於代碼功功能耦合在一起，通常是牽一髮動全身，一個微小的問題，都可能導致整個應用掛掉。這對於大型應用來說，是很不可行的。因此，有人提出能不能將每一個小的服務獨立開來，分別部署維護呢？如產品服務獨立成一塊，訂單服務獨立成一塊，用戶服務也獨立成一塊。這樣，每一個服務之間都不會有高耦合性，後期維護升級也更加方便。
是的，將每一個服務獨立部署分開維護，的確可以解決傳統開發中的高耦合性，但是我們也要考慮在傳統的開發方式中所有的服務都是本地的，UI可以直接調用，現在按功能拆分成獨立的服務，跑在獨立的服務器或進程中，客戶端UI如何互相訪問呢？
後臺有N個服務，前臺就需要記住管理N個服務，一個服務下線/更新/升級，前臺就要重新部署，這明顯不服務我們 拆分的理念，特別當前臺是移動應用的時候，通常業務變化的節奏更快。
另外，N個小服務的調用也是一個不小的網絡開銷。還有一般微服務在系統內部，通常是無狀態的，用戶登錄信息和權限管理最好有一個統一的地方維護管理（OAuth）。
因此，基於這些考慮，在上面的基礎上，有人又提出加入API網關層，用它來處理以下問題：
- ① 提供統一服務入口，讓微服務對前臺透明
- ② 聚合後臺的服務，節省流量，提升性能
- ③ 提供安全，過濾，流控等API管理功能
至此，一個簡單的微服務架構就誕生了。
服務之間如何通信
將每一個服務獨立部署後，肯定不能像傳統開發中使用類庫嵌套的方式調用其他服務。在微服務架構中，服務與服務之間的通信通常有兩種方式：
- ①同步調用
- ②異步調用
其中，同步調用又包括RPC方式和REST方式。
一般同步調用比較簡單，一致性強，但是容易出現調用問題，性能體驗上也會差些，特別是調用層次多的時候。
而異步調用在分佈式系統中有特別廣泛的應用，如異步消息，它既能降低調用服務之間的耦合，又能成為調用之間的緩衝，確保消息積壓不會沖垮被調用方，同時能保證調用方的服務體驗，繼續幹自己該乾的活，不至於被後臺性能拖慢。不過需要付出的代價是一致性的減弱，需要接受數據最終一致性。還有就是後臺服務一般要實現冪等性，因為出於性能的考慮，消息的發送一般會有重複（保證消息的被收到且僅收到一次對性能是很大的考驗）。最後就是必須引入一個獨立的broker，如 果公司內部沒有技術積累，對broker分佈式管理也是一個很大的挑戰。
服務註冊
在微服務架構中，一般每一個服務都是有多個拷貝的，每一個拷貝之間採用負載均衡的方式參與業務處理。一個服務隨時可能下線，也可能為應對臨時訪問壓力增加新的服務節點。那服務之間如何相互感知？多個服務如何管理呢？
這就設計到服務註冊了。服務註冊通常有客戶端方式和服務端方式兩種。不過其基本原理都是通過zookeeper等類似技術做服務註冊信息的分佈式管理。當服務上線時，服務提供者將自己的服務信息註冊到ZK（或類似框架），並通過心跳維持長鏈接，實時更新鏈接信息。服務調用者通過ZK尋址，根據可定製算法， 找到一個服務，還可以將服務信息緩存在本地以提高性能。當服務下線時，ZK會發通知給服務客戶端。
服務異常處理
前面提到，為避免傳統開發方式把所有雞蛋放在同一個籃子裡，一榮俱榮，一損俱損的問題，人們轉而採用服務獨立部署的方式，但獨立部署有一個很大的風險就是網絡是不可靠的，即網絡可能出現故障，如果這一塊沒有特別的保障，採用微服務架構結局肯定也是噩夢。那微服務如何保證整體業務鏈路不受網絡的影響或者把受到的影響降到最低呢？關於這一方面，微服務主要採用以下幾個手段：
- 重試機制：多試幾次
- 限流：減少到該服務的請求
- 熔斷機制：關閉該服務與其他服務之間的聯繫
- 負載均衡：將指定請求分配到指定服務
- 降級（本地緩存）：暫時關閉某些無關服務
閱讀更多 編碼之道 的文章
