1.微服務跟SOA有什么區別
可以把微服務當做去除了ESB的SOA。ESB是SOA架構中的中心總線，設計圖形應該是星形的，而微服務是去中心化的分布式軟件架構。
2.優點
每個服務足夠內聚，足夠小，代碼容易理解、開發效率提高；服務之間可以獨立部署，微服務架構讓持續部署成為可能；每個服務可以各自進行負載均衡擴展和數據庫擴展，而且，每個服務可以根據自己的需要部署到合適的硬件服務器上；容易擴大開發團隊，可以針對每個服務（service）組件開發團隊；提高容錯性（fault isolation），一個服務的內存泄露並不會讓整個系統癱瘓；系統不會被長期限制在某個技術棧上。
3.缺點
開發人員要處理分布式系統的復雜性；開發人員要設計服務之間的通信機制，對於需要多個后端服務的user case，要在沒有分布式事務的情況下實現代碼非常困難；涉及多個服務直接的自動化測試也具備相當的挑戰性；服務管理的復雜性，在生產環境中要管理多個不同的服務的實例，這意味着開發團隊需要全局統籌（PS：現在docker的出現適合解決這個問題）；應用微服務架構的時機如何把握？對於業務還沒有理清楚、業務數據和處理能力還沒有開始爆發式增長之前的創業公司，不需要考慮微服務架構模式，這時候最重要的是快速開發、快速部署、快速試錯。
4.微服務架構的關鍵問題
（1）微服務架構的通信機制
客戶端與服務器之間的通信
在單塊應用架構下，客戶端應用程序（web或者app）通過向服務端發送HTTP請求；但是，在微服務架構下，原來的單塊服務器被一組微服務替代，這種情況下客戶端如何發起請求呢？
客戶端可以向micro service發起RESTful HTTP請求，但是會有這種情況發生：客戶端為了完成一個業務邏輯，需要發起多個HTTP請求，從而造成系統的吞吐率下降，再加上無線網絡的延遲高，會嚴重影響客戶端的用戶體驗。
為了解決這個問題，一般會在服務器集群前面再加一個角色：API gateway，由它負責與客戶度對接，並將客戶端的請求轉化成對內部服務的一系列調用。這樣做還有個好處是，服務升級不會影響到客戶端，只需要修改API gateway即可。加了API gateway之后的系統架構圖如圖5所示。
內部服務之間的通信
內部服務之間的通信方式有兩種：基於HTTP協議的同步機制（REST、RPC）；基於消息隊列的異步消息處理機制（AMQP-based message broker）。
Dubbo是阿里巴巴開源的分布式服務框架，屬於同步調用，當一個系統的服務太多時，需要一個注冊中心來處理服務發現問題，例如使用ZooKeeper這類配置服務器進行服務的地址管理：服務的發布者要向ZooKeeper發送請求，將自己的服務地址和函數名稱等信息記錄在案；服務的調用者要知道服務的相關信息，具體的機器地址在ZooKeeper查詢得到。這種同步的調用機制足夠直觀簡單，只是沒有“訂閱——推送”機制。
AMQP-based的代表系統是Kafka、RabbitMQ等。這類分布式消息處理系統將訂閱者和消費者解耦合，消息的生產者不需要消費者一直在線；消息的生產者只需要把消息發送給消息代理，因此也不需要服務發現機制。
兩種通信機制都有各自的優點和缺點，實際中的系統經常包含兩種通信機制。例如，在分布式數據管理中，就需要同時用到同步HTTP機制和異步消息處理機制。
（2）分布式數據管理
處理讀請求
在線商店的客戶賬戶有限額，當客戶試圖下單時，系統必須判斷總的訂單金額是否超過他的信用卡額度。信用卡額度由CustomerService管理、下訂單的操作由OrderService負責，因此Order Service要通過RPC調用向Customer Service請求數據；這種方法能夠保證每次Order Service都獲取到准確的額度，單缺點是多一次RPC調用、而且Customer Service必須保持在線。
還有一種處理方式是，在OrderService這邊存放一份信用卡額度的副本，這樣就不需要實時發起RPC請求，但是還需要一種機制保證——當Customer Service擁有的信用卡額度發生變化時，要及時更新存放在Order Service這邊的副本。
處理更新請求
當一份數據位於多個服務上時，必須保證數據的一致性。
分布式事務（Distributed transactions） 使用分布式事務非常直觀，即要更新Customer Service上的信用卡額度，就必須同時更新其他服務上的副本，這些操作要么全做要么全不做。使用分布式事務能夠保證數據的強一致，但是會降低系統的可用性——所有相關的服務必須始終在線；而且，很多現代的技術棧並不支持事務，例如REST、NoSQL數據庫等。
基於事件的異步更新（Event-driven asynchronous updates） Customer Service中的信用卡額度改變時，它對外發布一個事件到“message broker（消息代理人）”；其他訂閱了這個事件的服務受到提示后就更新數據。
5.微服務架構的九大特性
服務組件化：
在微服務架構中，需要我們對服務進行組件化分解，服務是一種進程外的組件，它通過HTTP等通信協議進行協作，而不是像傳統組件那樣鑲入式的方式協同工作，每一個服務都獨立開發、部署、可以有效避免一個服務的修改引起整個系統的重新部署。
按業務組織團隊：
在實施微服務架構時，需要采用不同的團隊分割方法。由於每一個服務都是針對特定的業務的寬棧或者全棧實現的，紀要負責數據的持久化存儲，又要負責用戶接口定義等各種跨專業領域的職能。因此面對大型項目的時候，對於微服務團隊的拆分更加建議按業務線的方法進行拆分，一方面可以有效的減少服務內部修改所產生的內耗，另一方面，團隊邊界可以變得更為清晰。
做產品的態度：
在微服務架構團隊中，每個小團隊都應該以做產品的方式，，對其整個生命周期負責，而不是像傳統項目開發那樣，交付給測試，運維為目標
智能端點和啞管道：
由於各個服務不在一個進程中，組件間的通信模式發生了改變，原本進程內的方法調用變成了RPC方式的調用，會導致微服務之間產生煩瑣的通信，使得系統表現更為糟糕，所以我們需要更粗粒度的通信協議：
在微服務架構中，通常會使用一下兩種服務調用方法：
（1）使用HTTP的RESTful API或者輕量級的消息發送協議，實現消息傳遞與服務調用的處觸發。
(2) 通過在輕量級消息總線上傳遞消息，類似RabbitMQ等一些提供可靠異步交換的中間體。
在極度強調性能的情況下，還有可能會使用二進制的消息發送協議，例如protobuf
去中心化治理：
在整個微服務架構，通過采用輕量級的契約定義接口，使得我們隊服務本身的具體技術平台不再那么敏感，這樣整個微服務架構系統中的各個組件就能針對不同的業務特點選擇不同的技術平台。
去中心化管理數據：
在實施微服務架構時，希望每一個服務自己來管理其數據庫，這就是數據管理的去中心化，雖然數據管理的去中心化讓數據管理更加細致化，讓數據存儲和性能達到最優，但是不同的數據庫實例，數據一致性也成了微服務架構中亟待解決的問題之一，分布式事務本身實現的難度就非常大，所以在微服務架構中，我們更強調各服務之間進行”無事務“的調用，而對數據一致性，只要求數據在最后的處理狀態是一致的即可。
基礎設施自動化：
在微服務架構中，務必從一開始就構建起”持續交付“平台來支撐整個實施過程；
容錯設計：
在微服務架構中，快速檢測出故障源並盡可能地自動恢復服務是必須被設計考慮的，通常我們都希望在每個服務中實現監控和日志記錄的組件。比如：服務狀態、斷路器狀態、吞吐量、網絡延遲等關鍵數據的儀表盤等。
演進式設計
在初期， 以單體系統的方式來設計和實施， 一方面系統體量初期並不會很大， 構建和維護成本都不高。 另一方面， 初期的核心業務在后期通常也不會發生巨大的改變。
隨着系統的發展或者業務的需要， 架構師會將一些經常變動或是有一定時間效應的內容進行微服務處理， 並逐漸將原來在單體系統中多變的模塊逐步拆分出來， 而穩定不太變化的模塊就形成一個核心微服務存在於整個架構之中。
6.微服務的設計原則如下：
●單一職責原則
指的是每一個微服務模塊，只關心自己的業務規則。例如訂單模塊只關心訂單的相關業務，不牽扯其他業務的邏輯。
●服務自治原則
每一個微服務模塊的開發，需要有自己的開發、測試、運維、部署這一條獨立的棧，並且有自己的數據庫等一切，完全把其當成一個單獨的項目來做，不牽扯到其它無關業務。
●輕量級通信原則
微服務的通信協議需要跨平台、跨語言的通信協議，因為微服務是不綁定技術棧的，不論使用Java、PHP還是.net去開發Web系統，它們之間的通信一定是去語言特色的。
●接口明確原則
前面提到了微服務的“接口調整成本高”，那么怎么去避免它呢？我們一開始就應該規划好微服務的模塊是一種什么樣的模型，盡量去避免A接口的改動會導致B接口的改動這種情況。