什麼是微服務？
其實最近兩年微服務這個概念挺火的，那其實究竟什麼是微服務呢？
微服務其實是一種架構風格、一種約定。就和我們開發中使用的設計模式是一個道理。
每個微服務僅關注於完成一件任務
每個微服務獨立部署，互不干預
一個應用由一個或多個微服務組成
把我們上一文中的單體架構，拆分成微服務的結構，那麼應該是如下圖：
這裏我們將每個功能拆分爲一個單獨的服務，有自己的web容器，然後通過gateway連結起來，對外提供服務。用戶只和Gateway打交道，有點像是反向代理的感覺。
但這裏的拆分並不一定非得變爲這樣，你可以拆得更細，或者是更粗，視你業務情況而定，不要脫離業務談架構
這些服務之間如何通信？
我們將一個商城應用拆分爲如上圖所示後。當用戶購買一件商品時，要涉及到支付、修改購物車信息、修改商品庫存、發送短信通知 等多個服務。
當我們將整個單體架構拆爲這樣的微服務時，他們之間如何通信和協作呢？
通信方式
通信方式分爲同步、異步兩類
同步：
P2P
Gateway
P2P方式中，服務之間直接相互調用，每個服務都對外開放自己的API並調用其他服務的接口
Gateway方式中，服務之間相互調用也通過API網關P2P優點：少一次網絡IO
P2P缺點：無法做流量控制、無法記錄具體調用情況
Gateway調用方式的優缺點正好與之相反
異步：
消息中間件
一般用於下游服務執行時間不可控，或與調用者接下來邏輯無關聯的情況
一般同步通信下我們使用 HTTP RESTful 方式，異步下我們使用消息中間件（如消息隊列、發佈/訂閱等）
一般常用的消息格式爲 JSON
如何劃分你的團隊/服務 規模
2P2W 原則：
2 Pizza – 負責一個服務的團隊，不要讓兩個Pizza不夠分，也就意味着最好不要超過6個人，如果你服務粒度很小，那麼2-3個人也不是不行
2 Week – 一個團隊對其所負責的服務，如果要進行重構，時間不要超過2周，也就意味着太複雜或是工程太浩大的服務，需要考慮再次進行拆分
微服務的優點&挑戰
優點
簡單
一個服務只關注一個功能
擴容靈活
哪個服務需要擴容，就給哪個服務單獨做擴容
技術棧靈活
各團隊可以自行選擇最佳的技術棧來進行開發，例如Go支撐高性能服務， PHP支持普通業務
持續集成友好
允許我們在頻繁發佈不同服務的同時，保持系統其他服務的可用性
挑戰
需要技術積累
運維成本
需要構建/測試/部署/運行 數十個甚至更多的服務。不同的服務有不同的技 術棧，運維人員難以全部精通，開發人員纔是運維該服務的專家
人才稀缺
具有較強的DevOPS能力的人才稀缺。
分佈式系統帶來的問題
分佈式事務、網絡延遲/波動 等。
難以全面測試
需要自動化流程，不論是自動化測試還是自動集成，一般常用的質量保證 手段是上線後通過監控發現生產環境的異常，進而快速回滾或採取行動
劃重點
每個微服務是一個單體架構
每個微服務專注於一個功能
數據需要去中心化，每個微服務只能訪問自身的數據庫
一套微服務組合起來，對外提供一個完整的服務