服務架構是對 Moli
1. 將業務拆分為一個個獨立的服務。
2. 服務間通過 REST API 來將服務暴露出去，同時從 消耗服務API 來獲取其他模塊的服務。
由 《The Art of Scalability》 中的 Scale Cube 3D 模型來展示：
1. 微服務架構范式對應 Y 軸。
2. X軸由負載均衡器后端運行的多個應用副本組成。
3. Z軸（數據分割）將需求路由到相關服務
應用通常使用這三種不同類型的擴展：
Y 軸擴展將應用分解為 下圖 所示的微服務：
運行時，行程管理服務包括多個服務實例，每個服務實例都是一個 Docker 容器。
為了實現高可用性，這些容器運行在多個雲虛擬機上。
在應用實例前面是 NGINX 這樣的負載均衡，將請求分發給全部實例。
負載均衡也可以處理緩存、訪問控制、API 測量和監控等。
微服務架構范式對應用和數據庫的關系影響巨大。
每個服務都有自身的數據庫計划，而不與其他服務共享同一個數據庫。
一方面，類似企業級數據模型。
同時，也導致部分數據的重復。
為每個服務提供單個的數據庫計划非常必要。保證松散耦合。
每個服務都有其自己的數據庫。
此外，單個服務可以使用符合自己需要的特定類型的數據庫，即多語言一致性架構。
例如，駕駛管理服務必須使用高效支持地理位置請求的數據庫。
微服務架構的好處：
1. 通過分解巨大單體應用為多個服務方法解決了復雜性問題。在功能性不變的情況下，應用被分解為多個
可管理的分支或服務。每個服務都有一個用 RPC -- 或消息驅動 API 定義清楚的邊界。
單個服務很容易開發、理解和維護。
2. 微服務架構使得每個服務都可以有專門開發團隊來開發。開發團隊自由選擇開發技術，提供 API 服務。
這種自由意味着開發者不需要被迫使用某項目開始時采用的過時技術，可以選擇現在的技術。甚至於，因為服務都是相對簡單，即使用現在技術重寫以前代碼也不是很困難的事情。
3. 微服務架構模式使得每個微服務器獨立部署，不需要協調其他服務部署。可加快部署速度，
是的 持續化部署成為可能。
4. 微服務架構模式使得每個服務獨立擴展。
微服務的目的是有效的拆分應用，實現敏捷開發和部署。
微服務架構的不足
1. "there are no silver bullets" “微服務”強調了服務大小。
微服務的目的是有效的拆分應用，實現敏捷開發和部署。
2. 微服務應用是分布式系統，固有的復雜性，需要在 RPC 或者 消息傳遞之間選擇並完成進程間通訊機制。
但是，開發者必須寫代碼來處理消息傳遞中速度過慢或者不可能等局部失效問題。
但不是什么難事，相對於單體式應用中通過語言層級的方法或者進程調用，微服務下這種技術更復雜一些。
3. 一個關於微服務的挑戰來自於分區的數據庫架構。同時更新多個業務主體的事務很普遍。
這種事務對於單體式應用來說很容易，因為只有一個數據庫。
在微服務架構應用中，需要更新不同服務所使用的不同的數據庫。
不僅僅是 CAP 理論，當前高擴展的 NoSql 數據庫和消息傳遞中間件並不支持這一需求。需要一個最終一致性的方法。
4. 測試基於微服務架構的應用也很復雜。
微服務架構模式應用的改變會波及多個服務。幸運的是，許多改變一般只影響一個服務。
部署一個微服務應用也很復雜，一個單體應用需要在復雜均衡器后面部署給自的服務器就好了。
每個應用實例需要配置諸如數據庫和消息中間件等基礎服務。
相比之下，一個微服務應用一般由大批服務構成。每個應用實例是需要配置諸如數據庫和消息中間件等基礎服務。
很多的服務實例，就形成大量需要配置、部署、擴展和監控的部分。
除此之外，需要完成一個服務發現機制，以用來發現與它通訊服務的地址（包括服務器地址和端口）
以用來發現與它通訊服務的地址（包括服務器地址和端口）。
成功部署一個微服務應用需要開發者有足夠的控制部署方法，並高度自動化。
自動化的方法之一是使用 譬如 Cloud Foundry 這樣的 PaaS 服務。讓開發者輕松部署和管理微服務。，讓他們
無需為獲取並配置 IT 資源。配置 PaaS 的系統和網絡專家可以采用最佳實踐和策略來簡化這些問題。
另一個自動部署微服務應用的方法是開發自己的基礎 PaaS 系統。
通常的起步方式是 Mesos 或 Kubernetes 這樣的集群管理方案，配合 Docker 使用。
作為一種基於軟件的應用交付方法， NGINX 能夠方便地在微服務層面提供
1. 緩沖
2. 權限控制
3. API統計
4. 監控
-----------備注------------- （感謝技術分享）
[ Chris Richardson 微服務系列]
1 -- Ngnix 官方博客 微服務系列文章
2 -- 網頁： blog.daocloud.io/microservices-1/