一、什麼是微服務
微服務是系統架構中的一個風格，它的主旨是將一個原本獨立的系統拆分多個小型服務，這些服務都在各自的進程中運行。被劃分的每一個小型服務都是根據系統中某一項或者某一耦合度高的業務構建起來的，並且每個服務都維護自身的數據、業務開發、自動化測試案例以及獨立。由於有了輕量級的通信基礎，所以這些微服務可以用不同語言來編寫。
二、什麼是單體架構?有什麼優缺點？
在項目中，我們通常將需求分爲三個部分：數據庫、服務器處理、前端展示。如果這些需求都實現在了同一個應用中，那麼這個項目就是單體架構的。在項目發展初期，由於所有的業務邏輯寫在一個應用中，開發、測試、部署變得簡單高效。但是，隨着業務不斷擴大、需求不斷增多，代碼會越來越臃腫，系統變得難以維護。試想，當只需要修改一個很小的功能時，由於所以功能模塊都寫在同一個應用，重新部署會影響其他功能正常運行。另外，當項目太過龐大臃腫時，系統優化也是一道難題。每個功能模塊的併發量、使用場景、消耗的資源類型都不同，但是它們都在同一個應用中，這就使得我們對各個功能模塊的容量很難做出評估，難以對個別模塊進行優化。
三、微服務解決了單體結構帶來的哪些問題？
微服務的出現解決了單體結構隨着業務增長而日漸臃腫帶來的難以維護的問題。微服務將一個系統的不同功能拆分爲多個服務，每個服務都能獨立開發和部署。每個服務的更新、拓展都不會影響到其他服務的正常運行。此外，微服務的獨立部署還使得我們可以更準確地評估功能模塊的性能容量。
四、微服務產生了哪些問題？
1) 增加運維的難度。
運維人員由原先運維單體系統的一個進程到維護微服務架構的諸多進程，這無疑增加了運維的難度，需要運維人員具備更好的技術。
2) 需定義好API。
微服務之間的通訊依賴於API，需要服務端和客戶端定義好API，確保API可以在各個服務之間正常調用。API定義實質上依賴於選擇哪種IPC（交互式定義語言）。如果使用消息機制，API則由消息頻道（channel）和消息類型構成；如果選擇使用HTTP機制，API則由URL和請求、響應格式構成。
3) 分佈式帶來的問題。
由於微服務運行在各自的進程中，只能通過通信來進行協作，所以分佈式環境帶來的問題都需要被考慮進去，比如分佈式事務、網絡延遲或異常、異步消息。
4) 接口如何升級。
假設一個場景，某服務端的API接口要進行大規模升級，會使得新舊版本不兼容。因爲不能強制要求所有客戶端都立刻進行更新升級，所以服務端在進行API升級後仍需支持舊版本客戶端的請求。如果API定義爲RESTful接口，可以通過URL傳入版本號，服務器根據版本號再做相應處理。
5) 如何處理部分失敗。
如果服務端無法響應請求，那麼客戶端就是阻塞，一直等待服務端響應。這不僅會佔有系統資源，也會使得阻塞的客戶端越來越多，從而導致系統崩潰。
解決的方案有超時策略、限制請求數上限、斷路器模式等。