一、自我介紹
1、微服務架構（Microservice Architecture）是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦。你可以將其看作是在架構層次而非獲取服務的
類上應用很多SOLID原則。微服務架構是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務當中，從而降低系統的耦合性，並提供更加靈活的服務支持。
概念：把一個大型的單個應用程序和服務拆分爲數個甚至數十個的支持微服務，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協議。
定義：圍繞業務領域組件來創建應用，這些應用可獨立地進行開發、管理和迭代。在分散的組件中使用雲架構和平臺式部署、管理和服務功能，使產品交付變得更加簡單。
本質：用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題。
2、有一個圖非常好的總結微服務架構需要考慮的問題，包括：
1、API Gateway
2、服務間調用
3、服務發現
4、服務容錯
5、服務部署
6、數據調用
二、常見六兄弟
1、聚合器微服務設計模式
這是一種最常見也最簡單的設計模式：
聚合器調用多個服務實現應用程序所需的功能。它可以是一個簡單的Web頁面，將檢索到的數據進行處理展示。它也可以是一個更高層次的組合微服務，對檢索到的數據增加業務邏輯後進一步
發佈成一個新的微服務，這符合DRY原則。另外，每個服務都有自己的緩存和數據庫。如果聚合器是一個組合服務，那麼它也有自己的緩存和數據庫。聚合器可以沿X軸和Z軸獨立擴展。
2、代理微服務設計模式
這是聚合模式的一個變種，如下圖所示：
在這種情況下，客戶端並不聚合數據，但會根據業務需求的差別調用不同的微服務。代理可以僅僅委派請求，也可以進行數據轉換工作。
3、鏈式微服務設計模式
這種模式在接收到請求後會產生一個經過合併的響應，如下圖所示：
在這種情況下，服務A接收到請求後會與服務B進行通信，類似地，服務B會同服務C進行通信。所有服務都使用同步消息傳遞。在整個鏈式調用完成之前，客戶端會一直阻塞。
因此，服務調用鏈不宜過長，以免客戶端長時間等待。
4、分支微服務設計模式
這種模式是聚合器模式的擴展，允許同時調用兩個微服務鏈，如下圖所示：
5、數據共享微服務設計模式
自治是微服務的設計原則之一，就是說微服務是全棧式服務。但在重構現有的“單體應用（monolithic application）”時，SQL數據庫反規範化可能會導致數據重複和不一致。
因此，在單體應用到微服務架構的過渡階段，可以使用這種設計模式，如下圖所示：
在這種情況下，部分微服務可能會共享緩存和數據庫存儲。不過，這只有在兩個服務之間存在強耦合關係時纔可以。對於基於微服務的新建應用程序而言，這是一種反模式。
6、異步消息傳遞微服務設計模式
雖然REST設計模式非常流行，但它是同步的，會造成阻塞。因此部分基於微服務的架構可能會選擇使用消息隊列代替REST請求/響應，如下圖所示：
三、優點和缺點
1、微服務的優點：
關鍵點：複雜度可控，獨立按需擴展，技術選型靈活，容錯，可用性高
①它解決了複雜性的問題。它會將一種怪異的整體應用程序分解成一組服務。雖然功能總量 不變，但應用程序已分解爲可管理的塊或服務。每個服務都以RPC或消息驅動的API的
形式定義了一個明確的邊界；Microservice架構模式實現了一個模塊化水平。
②這種架構使每個服務都能夠由專注於該服務的團隊獨立開發。開發人員可以自由選擇任何有用的技術，只要該服務符合API合同。當然，大多數組織都希望避免完全無政府狀態並
限制技術選擇。然而，這種自由意味着開發人員不再有義務使用在新項目開始時存在的可能過時的技術。在編寫新服務時，他們可以選擇使用當前的技術。此外，由於服務相對較小，
因此使用當前技術重寫舊服務變得可行。
③Microservice架構模式使每個微服務都能獨立部署。開發人員不需要協調部署本地服務的變更。這些變化可以在測試後儘快部署。例如，UI團隊可以執行A | B測試，並快速迭代
UI更改。Microservice架構模式使連續部署成爲可能。
④Microservice架構模式使每個服務都可以獨立調整。您可以僅部署滿足其容量和可用性限制的每個服務的實例數。此外，您可以使用最符合服務資源要求的硬件。
2、微服務的缺點
關鍵點（挑戰）：多服務運維難度，系統部署依賴，服務間通信成本，數據一致性，系統集成測試，重複工作，性能監控等
①一個缺點是名稱本身。術語microservice過度強調服務規模。但重要的是要記住，這是一種手段，而不是主要目標。微服務的目標是充分分解應用程序，以便於敏捷應用程序開發和部署。
②微服務器的另一個主要缺點是分佈式系統而產生的複雜性。開發人員需要選擇和實現基於消息傳遞或RPC的進程間通信機制。此外，他們還必須編寫代碼來處理部分故障，
因爲請求的目的地可能很慢或不可用。
③微服務器的另一個挑戰是分區數據庫架構。更新多個業務實體的業務交易是相當普遍的。但是，在基於微服務器的應用程序中，您需要更新不同服務所擁有的多個數據庫。使用分佈式事務
通常不是一個選擇，而不僅僅是因爲CAP定理。許多今天高度可擴展的NoSQL數據庫都不支持它們。你最終不得不使用最終的一致性方法，這對開發人員來說更具挑戰性。
④測試微服務應用程序也更復雜。服務類似的測試類將需要啓動該服務及其所依賴的任何服務（或至少爲這些服務配置存根）。再次，重要的是不要低估這樣做的複雜性。
⑤Microservice架構模式的另一個主要挑戰是實現跨越多個服務的更改。例如，我們假設您正在實施一個需要更改服務A，B和C的故事，其中A取決於B和B取決於C.在單片應用程序中，
您可以簡單地更改相應的模塊，整合更改，並一次性部署。相比之下，在Microservice架構模式中，您需要仔細規劃和協調對每個服務的更改。例如，您需要更新服務C，然後更新服務B，
然後再維修A.幸運的是，大多數更改通常僅影響一個服務，而需要協調的多服務變更相對較少。
⑥部署基於微服務的應用程序也更復雜。單一應用程序簡單地部署在傳統負載平衡器後面的一組相同的服務器上。每個應用程序實例都配置有基礎架構服務（如數據庫和消息代理）
的位置（主機和端口）。相比之下，微服務應用通常由大量服務組成。例如，每個服務將有多個運行時實例。更多的移動部件需要進行配置，部署，擴展和監控。此外，您還需要實現服務
發現機制，使服務能夠發現需要與之通信的任何其他服務的位置（主機和端口）。傳統的基於故障單和手動操作的方法無法擴展到這種複雜程度。因此，成功部署微服務應用程序需要
開發人員更好地控制部署方法，並實現高水平的自動化。
參考地址：https://www.cnblogs.com/linezero/archive/2017/02/06/microservices.html
初來乍到，學藝不精，略懂皮毛，還望相互學習，多多指教~