1.那些組件是微服務必備的？
- 首先我們需要沿用現有的技術體系開發一個單一職責的系統
- 單一職責的系統需要對外提供服務，服務提供方需要將自己的地址信息等存儲在註冊中心
- 調用此係統的服務消費者通過註冊中心獲取服務端地址進行遠程調用
- 通過爲服務網關作爲統一入口，用來做流量控制，限流，身份鑑別等操作
針對1-3 我們需要一個註冊中心
針對第四點 我們需要api網關
幾個概念：
註冊中心：服務提供方在註冊中心註冊，記錄自己的位置和提供的服務
服務發現：服務消費方在註冊中心尋找服務的過程
LB（負載均衡）：假設消費者由100個，調用提供者由50個，假如這100個消費者產生了2000次的調用，如果這些請求都交給一個提供者去處理，那麼這個提供者就可能掛掉，所以我們需要一個程序去讓我們的請求大致平均的分不到各個提供者中
LB的方案大概有以下幾種：(輪詢，隨機，最少相應，最少併發數等)
- 集中式負載，即負載均衡在服務端做，這樣的壞處是LB容易成爲系統性能的瓶頸
- 客戶端負載也叫軟負載，即在客戶端實現負載均衡 軟負載中的privider除了需要註冊外還需要定時發送心跳
- 主機獨立式負載均衡 即在服務端單獨開一個進程做LB與服務發現
3.擴展
正向代理就是用戶不能直接訪問我們內部的系統，但是代服務器可以，所以用戶訪問代理服務器，代理服務器訪問我們的系統 然後我們的服務返回信息給代理服務器，代理服務器返回給用戶。
反向代理是
反向代理的服務器是在我們系統內部，客戶端感知不到代理服務器的存在。
正向代理與反向代理的最大區別就是 正向代理需要客戶端配置代理服務器的ip等信息，反向代理由我們系統內部實現，客戶端是無感知的。
4微服務的部署依賴於docker容器
所以程序包需要打包成與環境無關的也就是說不能含有環境等的配置信息，所以需要引入配置中心組件
5關於微服務的幾個問題
- 客戶端怎麼訪問這些微服務：前端如何訪問後臺
答：通過微服務API網關，網管的作用是1.聚合後臺服務節省流量 2.提供統一的服務入口，讓微服務對前臺透明 3.提供安全過濾流量控制等功能 - 服務間如何調用？如何通信？
- rpc調用
- rest 直接通過http請求
- mq 異步消息調用
6一個demo級別的微服務架構
前端/客戶端/app通過發送請求到api網關：api網關決定調用哪個服務，其中服務與服務之間的註冊與服務發現是通過註冊中心來實現的，每個服務都有自己的獨立的數據庫，也就是說去中心化的數據庫。通過配置中心獲取配置，來實現環境無關性。
（可選操作：爲了便於維護管理可添加一個監控中心）
7 微服務的設計模式
微服務設計模式有很多種：
1.聚合模式：
2. 代理模式
3. 鏈式模式
4.分支模式
5.異步消息模式
6.數據共享模式
說明：1. 聚合模式會將多個服務的結果排序或去重，簡單的說就是聚合器可以調用多個服務來實現另一個更高級或者簡單的服務，聚合服務也可以單獨抽象出一個微服務，擁有自己獨立的緩存和數據庫。
2. 代理模式：代理模式是聚合模式的變種，代理並不聚合數據，但會根據業務需求的差別調用不同的微服務。代理可以僅僅委派請求，也可以進行數據轉換工作。
個人理解：代理模式就是決定調用哪一個微服務完成功能，聚合模式就是決定調用那些微服務來實現功能
3.鏈式模式：鏈式模式就是一次調用每個微服務來完成服務，適用於交易訂單等業務場景，要求調用的微服務按一定順序才能完成相應的功能
4.分支模式：分支模式可以理解爲聚合模式與鏈式模式的結合，聚合模式聚合單個微服務，分支模式就是聚合多個鏈式微服務。
5.異步消息模式：實現的功能不需要立即響應，不會阻塞客戶端，客戶端把消息放到消息隊列中即可，各個微服務自己去消費這些消息
6.數據共享模式：每個微服務的存儲的數據可能會很少，或者單體服務向微服務轉變是有一些強耦合的數據。這樣會有部分微服務共用一個數據庫，而不是獨立的了
以上僅僅是本人初步理解，還在學習中，有不當之處歡迎指正，我也會在以後的學習中不斷修正