通過以上定義和描述，我們基本可以確定微服務的截面特征:
要將微服務實踐到生產項目中，首先要考慮壹些問題。例如，微服務業務架構如下所示:
在上圖所示的架構圖中，我們假設商家服務A、訂單服務B和產品服務C被拆分到壹個微服務應用程序中，並分別進行部署。此時，我們面臨著許多可能需要解決的問題，例如:
1.客戶如何訪問這些服務？
2.各服務之間如何溝通？
3.多微服務如何實現？
4.服務異常宕機怎麽辦？
這些都是需要逐壹解決的問題。
在單個應用的開發中，所有服務都是本地的，前端UI界面和手機APP程序可以直接訪問後端服務器程序。
現在它按功能拆分成獨立的服務，在獨立的進程中運行。如下圖所示:
此時，後臺有n個服務，前臺需要記住管理n個服務。當壹個服務離線、更新、升級後，前臺和手機APP會重新部署或重新簽約，這顯然不符合我們拆分的概念。特別是對於當前業務需求的快速發展，業務變更非常頻繁。
除了訪問管理上的困難，n個小服務的調用也是很大的網絡開銷。另外，壹般的微服務在系統內通常是無狀態的，而我們的用戶經常跨業務模塊操作，需要有狀態。這個問題目前無法在這個系統架構中解決。傳統上有壹個統壹的本地維護管理(OAuth)來解決用戶登錄信息和權限管理，我們稱之為授權管理。
基於以上列舉的問題，我們采用了壹種叫做Gateway(英文API Gateway)的技術方案來解決這些問題。網關的功能主要包括:
API Gateway的實現方式有很多種，可以是軟硬壹體的盒子，簡單的MVC框架，甚至可以是Node.js服務器。它們最重要的作用是為前臺(通常是移動應用)提供後臺服務的聚合，提供統壹的服務出口並將它們解耦，但API Gateway也可能成為單點故障或性能瓶頸。
最後，帶有API Gateway的業務架構圖更改如下:
所有的微服務都是在自己的進程容器中獨立部署和運行的，所以微服務之間的通信就是IPC(進程間通信)，翻譯過來就是進程間通信。進程間通信的方案已經比較成熟，現在最常見的有兩種:同步調用和異步消息調用。
同步呼叫
同步調用簡單且壹致，但容易出現調用問題，性能體驗會更差，尤其是在調用級別很多的情況下。同步調用有兩種實現方式:REST和RPC。
基於REST和RPC的特點，我們通常采用以下原則:用REST向系統外部公開，用RPC向系統內部公開調用。
異步消息傳遞廣泛應用於分布式系統中。既能降低調用服務之間的耦合，又能充當調用之間的緩沖，保證消息積壓不會沖走被調用方，同時保證調用方的服務體驗，繼續做自己該做的事，不會被後臺性能拖慢。要付出的代價是壹致性的弱化，需要接受數據最終的壹致性。所謂最終壹致性，是指同步可能不會馬上完成，會有延遲，但數據同步最終會完成；此外，後臺服務壹般需要達到冪等性，因為出於性能考慮，消息發送壹般會重復進行(保證消息只接收壹次，對性能是壹個很大的考驗)。最後，必須引入壹個獨立的代理作為中間代理池。
異步消息調用的常見框架有:Kafaka、Notify和MessageQueue。
最後，大多數服務間調用體系結構的實現如下:
在微服務架構中，每個服務壹般都有多個副本用於負載平衡。服務可能隨時脫機，或者可能添加新的服務節點來響應臨時訪問壓力。這提出了壹個新問題:
這就是服務發現、識別和管理的問題。解決多個服務之間的標識，發現的問題壹般都是通過註冊的方式進行。
具體來說，服務上線時，服務提供者將其服務註冊信息註冊到壹個專門的框架中，通過heartbeat維護壹個長鏈接，實時更新鏈接信息。服務調用方通過服務管理框架尋址，根據特定的算法找到相應的服務，或者在本地緩存服務的註冊信息，從而提高性能。當壹個服務離線時，服務管理框架會向其他服務發送服務離線的通知。
常見的服務管理框架有:Zookeeper等框架。
針對上述問題有兩種具體的解決方案，即基於客戶端的服務註冊和發現以及基於服務器的服務註冊和發現。
優點是架構簡單，擴展靈活，只依賴服務註冊中心。缺點是客戶端維護調用服務的所有地址在技術上很困難。壹般大公司都有成熟的內部框架支持。
好處是所有服務對前臺調用者透明，壹般采用小公司在雲服務上部署的應用。
前面說過，單個應用開發的壹個很大的風險就是孤註壹擲，壹榮俱榮，壹損俱損。分發最大的特點就是網絡不可靠。這種風險可以通過微服務拆分來降低，但如果沒有特別的保障，結局肯定是噩夢。
因此，當我們的系統由壹系列服務調用鏈組成時，我們必須確保任何壹個鏈路故障都不會影響整個鏈路。相應的手段有很多，比如: