接觸微服務，我們一定會有這樣的幾個問題：微服務如何管理？如何調用？如何訪問？如何容錯？如何排錯？帶着這些問題，我們來看一下微服務的架構設計。
一、服務治理
服務治理就是進行服務的自動化管理，其核心是服務的自動注冊與發現。
服務注冊就是服務實例將自身服務信息注冊到注冊中心。
服務發現就是服務實例通過注冊中心，獲取服務實例的信息，通過這些信息去請求他們提供的服務。
服務剔除就是服務注冊中心將出問題的服務自動剔除到可用列表之外，使其不會被調用。
二、服務調用
在微服務架構中，通常存在多個服務之間的遠程調用請求。目前主流的遠程調用技術有基於HTTP的RESTful接口以及基於TCP的RPC協議。
REST（Representational State Transfer）是一種HTTP的調用格式，更標准，更通用。
RPC（Remote Promote Call）一種進程間通信方式，允許像調用本地服務一樣調用遠程服務。RPC框架的主要目標就是讓遠程服務調用更簡單、透明。RPC框架負責屏蔽底層的傳輸方式、序列化方式和通信細節。開發人員在使用的時候只需要了解誰在什么位置提供了什么樣的遠程服務接口即可，並不需要關心通信細節和調用過程。
區別與聯系
三、服務網關
隨着微服務的不斷增多，不同的微服務一般會有不同的網絡地址，而外部客戶端可能需要調用多個服務的接口才能完成一個業務需求。
如果讓客戶端直接與各個微服務通信，可能會出現很多問題：客戶端需要調用不同的url地址，增加難度；在一定場景下存在跨域請求問題；每個微服務都需要進行單獨的身份認證。
針對上述問題，API網關順勢而生。API網關就是將所有API調用統一接入到API網關層，由網關統一接入和輸出。一個網關的基本功能有：統一接入、安全防護、協議適配、流量管控、長短鏈支持、容錯能力。有了網關之后，各個API服務提供團隊可以專注自己的業務邏輯處理，而API網關更專注於安全、流量、路由等問題。
四、服務容錯
在微服務中，一個請求經常會涉及到調用幾個服務，如果其中某個服務不可用，沒有做服務容錯的話，極有可能會造成過一連串的服務不可用，這就是雪崩效應。
我們無法預防雪崩效應的發生，只能盡可能去做好服務容錯，服務容錯的三個核心思想是：不被外界環境影響，不被上游請求壓垮，不被下游響應壓垮。
五、鏈路追蹤
隨着微服務架構的流行，服務按照不同的維度進行拆分，一次請求往往要涉及多個服務。互聯網應用構建在不同軟件模塊集上，這些軟件模塊，由可能是不同的團隊開發、可能使用不同的編程語言來實現、有可能布在了幾千台服務器，橫跨多個不同的數據中心。因此，就需要對一次請求涉及多個服務鏈路進行日志記錄，性能監控即鏈路追蹤。
