微服務--整體...
微服務 ---- “微”？ “服務”？
微 ： 體積小
服務 ： 不同於系統 ， 服務一個或者一組相對較小且獨立的功能單元 ，是使用者可以感知到的最小單位 ！
廣義 ： 分散式系統解決方案，推動細粒度服務的使用，讓這些服務協同合作！
《微服務》 與 《微服務框架》 的區別？
微服務架構 ： 是將複雜的系統使用元件化的方式進行拆分，並使用輕量級通訊方式（protobuf）進行整合的一種設計方法。
微服務 ：是通過 《微服務架構》這種架構方法拆分出來的一個獨立的元件化的小應用。
微服務架構定義的精髓 ---- “分而治之，合而用之”
將複雜的事情拆分成小事情來做 ， 通過輕量級通訊等方式把拆分的東西進行整合，使微小的功能合起來做大事情 。 ----- 例如，積木，機甲合體之類的。
《單體架構》 缺點 ：
1、複雜性逐漸變高 ：巨多的程式碼，各個模組之間區別比較模糊，邏輯不夠用清晰，程式碼越多越複雜，遇到的問題越難解決。
2、技術債務逐漸上升 ：公司人員流動，before 留下的坑 ， 由於“ 複雜性逐漸變高 ”的原因，使 new 很難發現和解決.............在人員流動的這個長期過程中，問題逐漸變多，變大，變難------這就是 技術債務逐漸上升 ！
3、維護成本大 ：應用程式功能越來越多、團隊越來越大時，溝通成本、管理成本顯著增加。複雜性的逐漸提升，導致在維護時修改bug容易引入新的bug。
4、持續交付週期長 ：隨著程式碼變多，變複雜，任何一個修改都有可能踩坑，一旦踩坑，就會拖延交付的時間...
5、技術選型成本高 ：單體架構傾向於採用統一的技術平臺獲方案來解決所有問題，如果想引進新的技術或方法，成本和風險都很大。
6、可擴充套件性差 ：隨著功能的增加，垂直擴充套件的成本將會越來越大；而對於水平擴充套件而言，因為所有程式碼都執行在同一個程序，沒辦法做到針對應用程式的部分功能做獨立的擴充套件。
《微服務架構的特性》優點：
1、單一職責 ：微服務架構中的每個服務，都是具有業務邏輯的，符合高內聚、低耦合原則以及單一職責原則的單元，不同的服務通過“管道”的方式靈活組合，從而構建出龐大的系統。
2、輕量級通訊 ：（ protobuf ） 服務之間通過輕量級的通訊機制實現互通互聯，而所謂的輕量級，通常指語言無關、平臺無關的互動方式。
3、獨立性 ： 每個服務在應用交付過程中，獨立地開發、測試和部署。
4、程序隔離 ： 在微服務架構中，應用程式由多個服務組成，每個服務都是高度自治的獨立業務實體，可以執行在獨立的程序中，不同的服務能非常容易地部署到不同的主機上。
《微服務架構的特性》缺點：
1、運維要求極高 ： 對於單體架構來講，我們只需要維護好這一個專案就可以了，但是對於微服務架構來講，由於專案是由多個微服務構成的，每個模組出現問題都會造成整個專案執行出現異常，想要知道是哪個模組造成的問題往往是不容易的，因為我們無法一步一步通過debug的方式來跟蹤，這就對運維人員提出了很高的要求。
2、分散式的複雜性 ：對於單體架構來講，我們可以不使用分散式，但是對於微服務架構來說，分散式幾乎是必會用的技術，由於分散式本身的複雜性，導致微服務架構也變得複雜起來。
3、介面調整成本高 ：比如，使用者微服務是要被訂單微服務和電影微服務所呼叫的，一旦使用者微服務的介面發生大的變動，那麼所有依賴它的微服務都要做相應的調整，由於微服務可能非常多，那麼調整介面所造成的成本將會明顯提高。
4、重複勞動 ：對於單體架構來講，如果某段業務被多個模組所共同使用，我們便可以抽象成一個工具類，被所有模組直接呼叫，但是微服務卻無法這樣做，因為這個微服務的工具類是不能被其它微服務所直接呼叫的，從而我們便不得不在每個微服務上都建這麼一個工具類，從而導致程式碼的重複。
選擇《微服務架構》的理由！
1、開發簡單 ：微服務架構將複雜系統進行拆分之後，讓每個微服務應用都開放變得非常簡單，沒有太多的累贅。對於每一個開發者來說，這無疑是一種解脫，因為再也不用進行繁重的勞動了，每天都在一種輕鬆愉快的氛圍中工作，其效率也會整備地提高。
2、快速響應需求變化 ：一般的需求變化都來自於區域性功能的改變，這種變化將落實到每個微服務上，二每個微服務的功能相對來說都非常簡單，更改起來非常容易，所以微服務非常適合敏捷開發方法，能夠快速的影響業務的需求變化。
3、隨時隨地更新 ：一方面，微服務的部署和更新並不會影響全域性系統的正常執行；另一方面，使用多例項的部署方法，可以做到一個服務的重啟和更新在不易察覺的情況下進行。所以每個服務任何時候都可以進行更新部署。
4、系統更加穩定可靠 ：微服務執行在一個高可用的分散式環境之中，有配套的監控和排程管理機制，並且還可以提供自由伸縮的管理，充分保障了系統的穩定可靠性。
protocol buffer ---- 輕量級通訊方式
簡介 ：
Google Protocol Buffer (簡稱 Protobuf )是google旗下的一款輕便高效的結構化資料儲存格式，平臺無關、語言無關、可擴充套件，可用於通訊協議和資料儲存等領域。所以很適合用做資料儲存和作為不同應用，不同語言之間相互通訊的資料交換格式，只要實現相同的協議格式即同一 proto檔案被編譯成不同的語言版本，加入到各自的工程中去。這樣不同語言就可以解析其他語言通過 protobuf序列化的資料。目前官網提供了 C++,Python,JAVA,GO等語言的支援。google在2008年7月7號將其作為開源專案對外公佈。
tips ：
啥叫平臺無關？ Linux 、 mac 和 Windows 都可以用，32位系統，64位系統通吃
啥叫語言無關？ C++ 、 Java 、 Python 、 Golang 語言編寫的程式都可以用，而且可以相互通訊那啥叫可擴充套件呢？就是這個資料格式可以方便的增刪一部分欄位啦~
最後啥叫序列化啊？解釋得通俗點兒就是把複雜的結構體資料按照一定的規則編碼成一個位元組切片
protobuf的優勢與劣勢優勢 ：
優勢 ：
1：序列化後體積相比Json和XML很小，適合網路傳輸
2：支援跨平臺多語言 3：訊息格式升級和相容性還不錯
4：序列化反序列化速度很快，快於Json的處理速度
劣勢 ：
1：應用不夠廣(相比xml和json)
2：二進位制格式導致可讀性差
3：缺乏自描述
GRPC
gRPC 是一個高效能、開源和通用的 RPC 框架，面向移動和 HTTP/2 設計。
gRPC基於 HTTP/2標準設計，帶來諸如雙向流、流控、頭部壓縮、單 TCP連線上的多複用請求等特。這些特性使得其在移動裝置上表現更好，更省電和節省空間佔用。
具體：
在 gRPC裡客戶端應用可以像呼叫本地物件一樣直接呼叫另一臺不同的機器上服務端應用的方法，使得您能夠更容易地建立分散式應用和服務。與許多 RPC系統類似， gRPC也是基於以下理念：
1、定義一個服務，指定其能夠被遠端呼叫的方法（包含引數和返回型別）。
2、在服務端實現這個介面，並執行一個 gRPC伺服器來處理客戶端呼叫。
3、在客戶端擁有一個存根能夠像服務端一樣的方法。 gRPC客戶端和服務端可以在多種環境中執行和互動 -從 google內部的伺服器到你自己的筆記本，並且可以用任何 gRPC支援的語言 來編寫。
RPC
RPC（Remote Procedure Call Protocol） ——遠端過程呼叫協議，它是一種通過網路從遠端計算機程式上請求服務，而不需要了解底層網路技術的協議。
簡單來說，就是跟遠端訪問或者web請求差不多，都是一個client向遠端伺服器請求服務返回結果，但是web請求使用的網路協議是http高層協議，而rpc所使用的協議多為TCP，是網路層協議，減少了資訊的包裝，加快了處理速度。
grpc的例項執行順序
服務發現
圖中，客戶端的一個介面，需要呼叫服務A-N。客戶端必須要知道所有服務的網路位置的，以往的做法是配置是配置檔案中，或者有些配置在資料庫中。這裡就帶出幾個問題：
需要配置N個服務的網路位置，加大配置的複雜性
服務的網路位置變化，都需要改變每個呼叫者的配置
叢集的情況下，難以做負載（反向代理的方式除外）
總結起來一句話：服務多了，配置很麻煩，問題多多
那麼，就產生了 服務發現 ：下圖
與之前一張不同的是，加了個 服務發現 模組。圖比較簡單，這邊文字描述下。
服務A-N把當前自己的網路位置註冊到服務發現模組（這裡註冊的意思就是告訴），服務發現就以K-V的方式記錄下，K一般是服務名，V就是IP:PORT。服務發現模組定時的輪詢檢視這些服務能不能訪問的了（這就是健康檢查）。客戶端在呼叫服務A-N的時候，就跑去服務發現模組問下它們的網路位置，然後再呼叫它們的服務。這樣的方式是不是就可以解決上面的問題了呢？客戶端完全不需要記錄這些服務網路位置，客戶端和服務端完全解耦！
下面的例子有助於我們理解服務發現的形式：
例如：
郵遞員去某公司一棟大樓投遞快件，向門衛詢問員工甲在哪一個房間，門衛拿起桌上的通訊錄查詢，告知郵遞員員工甲在具體什麼位置。假如公司來了一個員工乙，他想讓郵遞員送過來，就要先讓門衛知道自己在哪一個房間，需要去門衛那邊登記，員工乙登記後，當郵遞員向門衛詢問時，門衛就可以告訴郵遞員員工乙的具體位置。門衛知道員工乙的具體位置的過程就是服務發現，員工乙的位置資訊可以被看作服務資訊，門衛的通訊錄就是上文中提到的資料交換格式，此例中員工乙就是上文的已方，門衛就是服務發現的提供者。
正向代理
正向代理 ，意思是一個位於客戶端和原始伺服器(origin server)之間的伺服器，為了從原始伺服器取得內容，客戶端向代理髮送一個請求並指定目標(原始伺服器)，然後代理向原始伺服器轉交請求並將獲得的內容返回給客戶端。所以已知我們目標的原始服務。
反向代理
反向代理 是代理伺服器的一種。伺服器根據客戶端的請求，從其關係的一組或多組後端伺服器（如Web伺服器）上獲取資源，然後再將這些資源返回給客戶端，客戶端只會得知反向代理的IP地址，而不知道在代理伺服器後面的伺服器簇的存在
負載均衡
負載均衡 （Load Balance） 其意思就是分攤到多個操作單元上進行執行，例如Web 伺服器 、 FTP伺服器 、 企業 關鍵應用伺服器和其它關鍵任務伺服器等，從而共同完成工作任務。
Consul
一套微服務框架中有多個服務需要管理，也就是說會有多個 gRPC ， 一個一個管理會很繁瑣，所以我們需要一個管理髮現的機制。 ---------- Consul
所謂 Consul 是啥 ？
它具備以下特性 :
服務發現 ：consul通過DNS或者HTTP介面使服務註冊和服務發現變的很容易，一些外部服務，例如saas提供的也可以一樣註冊。
健康檢查 ：健康檢測使consul可以快速的告警在叢集中的操作。和服務發現的整合，可以防止服務轉發到故障的服務上面。
鍵/值儲存 ：一個用來儲存動態配置的系統。提供簡單的HTTP介面，可以在任何地方操作。
多資料中心 ：無需複雜的配置，即可支援任意數量的區域。
執行 Consul代理 ：Consul是典型的 C/S架構，可以執行服務模式或客戶模式。每一個數據中心必須有至少一個服務節點， 3到5個服務節點最好。非常不建議只執行一個服務節點，因為在節點失效的情況下資料有極大的丟失風險。
Consul的client mode把請求轉向server，那麼client的作用是什麼？
consul可以用來實現分散式系統的服務發現與配置。client把服務請求傳遞給server，server負責提供服務以及和其他資料中心互動。題主的問題是，既然server端提供了所有服務，那為何還需要多此一舉地用client端來接收一次服務請求。我想，採用這種架構有以下幾種理由：
首先 server端的網路連線資源有限。對於一個分散式系統，一般情況下訪問量是很大的。如果使用者能不通過client直接地訪問資料中心，那麼資料中心必然要為每個使用者提供一個單獨的連線資源(執行緒，埠號等等)，那麼server端的負擔會非常大。所以很有必要用大量的client端來分散使用者的連線請求，在client端先統一整合使用者的服務請求，然後一次性地通過一個單一的連結傳送大量的請求給server端，能夠大量減少server端的網路負擔。
其次 ，在client端可以對使用者的請求進行一些處理來提高服務的效率，比如將相同的請求合併成同一個查詢，再比如將之前的查詢通過cookie的形式快取下來。但是這些功能都需要消耗不少的計算和儲存資源。如果在server端提供這些功能，必然加重server端的負擔，使得server端更加不穩定。而通過client端來進行這些服務就沒有這些問題了，因為client端不提供實際服務，有很充足的計算資源來進行這些處理這些工作。
最後還有一點 ，consul規定只要接入一個client就能將自己註冊到一個服務網路當中。這種架構使得系統的可擴充套件性非常的強，網路的拓撲變化可以特別的靈活。這也是依賴於client—server結構的。如果系統中只有幾個資料中心存在，那網路的擴張也無從談起了。
Micro
Micro解決了構建雲本地系統的關鍵需求。它採用了微服務體系結構模式，並將其轉換為一組工具，作為可伸縮平臺的構建塊。Micro隱藏了分散式系統的複雜性，併為開發人員提供了很好的理解概念。
Micro是一個專注於簡化分散式系統開發的微服務生態系統。是一個工具集合, 通過將微服務架構抽象成一組工具。隱藏了分散式系統的複雜性，為開發人員提供了更簡潔的概念。
關於外掛化
Go Micro跟其他工具最大的不同是它是外掛化的架構，這讓上面每個包的具體實現都可以切換出去。舉個例子，預設的服務發現的機制是通過Consul，但是如果想切換成etcd或者zookeeper 或者任何你實現的方案，都是非常便利的。