一、服務的三要素
一個網絡服務主要包括以下三個要素：
地址： 調用方需要根據地質訪問網絡。IP地址、服務端口、服務協議；
協議格式： 協議都有哪些字段
協議名稱： 或者叫協議類型，用協議類型（名稱）區分不同的網絡接口。
服務調用的尋址過程如下：
名詞解釋：
服務實例： 服務對應的IP地址加端口的簡稱。
服務註冊： 某個服務實例宣稱自己提供了哪些服務，即某個IP地址+端口都提供了哪些服務接口。
服務發現： 調用方通過某種方式找到提供方，即知道服務運行的IP+端口。
服務註冊是服務器的行爲，服務發現是客戶端的行爲叭。
二、具體如何調用
2.1 調用方式
2.1.1 基於IP地址的調用
即把IP地址暴露給調用者，缺點如下：
IP地址難於記憶且無意義；
如果使用IP地址進行尋址，則換機器就很麻煩。
所以，這種方式很不合理，不建議使用。
2.1.2 域名系統
域名系統的優點很明顯，一個是名字有意義好記憶，而是，就算更換機器，也只需要更換域名對應的IP即可。
調用鏈：用戶訪問域名 -》 根據DNS協議解析IP地址 -》根據IP地址訪問服務。
2.2 協議的接收和解析
一個網絡協議主要包含兩部分：
**協議包頭：**存儲協議的元信息，包括協議類型、報體長度、協議格式等；有固定大小，或者明確邊界。
**協議包體：**具體的協議內容。
一般會採用狀態機來做協議數據的接收：
一個協議，有多個字段，而不同的字段有不同的類型，該如何解析呢？常見手段：
使用json或者xml這樣的數據結構 ，容易看明白，但是會容易被破解，且數據較大。
使用二進制協議，TVL格式（Type - Length - Value），但是可視性較差，容易出錯。
google的Protocol Buffer（PB）：具體如下：
優點：
1、使用proto格式（DSL（domain-specific language）文件）來定義協議，文中描述了協議的具體格式，每個字段的類型，字段是可選字段還是必選字段，客服端和服務器通過這個文件來進行協議的溝通和交流，而不是具體的技術細節。
2、PB能通過proto文件生成各種語言對應的序列化反序列化代碼，利於跨語言調用。
3、PB能對特定類型的數據進行壓縮，減少數據大小。
2.3 服務網關
隨着越來越豐富的業務，單機服務器負載不了，肯定要多加服務器的。
2.3.1 在DNS解析的時候處理
在DNS解析的時候，將域名與多個地址進行綁定。
缺點：
1、如何監控實例的情況，做到發現問題的時候增刪實例地址?
2、把這些服務暴露給外網，是否安全？
3、DNS增刪服務並不是實時的，可能會影響到業務。
2.3.2 網關接入層
反向代理網關，提供功能：
負載均衡： 把所有的請求儘可能平均的分配到服務器上；
提供管理功能： 管理服務實例；
因爲可以決定服務請求流量的走向，所以還可以做 灰度引流，安全防攻擊等。
常見的負載均衡軟件有兩種，四層和七層。
四層：LVS （用於TCP協議）
七層：nginx（用於HTTP協議）
（1）、四層負載均衡：LVS
終端互聯網用戶從外部訪問公司的外部負載均衡服務器，終端用戶的Web請求會發送給LVS調度器，調度器根據自己預設的算法決定將該請求發送給後端的某臺Web服務器。
（2）、七層負載均衡：Nginx
系統內部要訪問外網的時候，統一通過一個代理服務器把請求發出去，代理服務器實現的就是正向代理。
如果有外部請求進入系統的時候，代理服務器把這些請求集中轉發到某臺服務器上，此時，代理服務器實現的就是反向代理。
所以，正向代理就是代理服務器代替系統內部向外發起請求的過程，而反向代理是外部請求通過代理服務器轉發到內部服務器的過程。
反向代理的好處：
a.將請求均衡的發送給web服務器。
b.只用將反向代理服務器的地址暴露出去，做到限流、安全等。
c.統一接入客戶端的請求，可以在反向代理的接入層做更多的控制，比如灰度流量發佈、權重控制等。
2.4 服務發現與RPC
提供給外網的服務一般以域名的方式提供出去即可，對於服務內部之間的相互調用，只有域名系統往往不夠。所以需要一個“服務發現”類的系統，主要包括：
（1）、服務發現系統：用於提供服務的尋址，註冊能力，以及統計服務狀態，根據服務情況更改服務的調用情況等；
（2）、一套與服務發現系統配合使用的RPC庫；
RPC庫提供的功能：
（1）、服務提供方：使用RPC庫註冊自己的服務到服務發現系統，上報自己的服務情況；
（2）、服務調用方：使用RPC庫進行尋址服務，實時從服務發現系統獲取最新的服務調度策略；
（3）、提供協議的序列化、反序列化功能，負載均衡的調用策略、熔斷限流等安全訪問策略；
優點：
1、業務邏輯無需關注服務地址、協議解析、服務調度、自身服務情況上報等工作，只需關注業務邏輯即可；
2、可以通過管理後臺界面，對服務的策略進行修改和查看等；
3、服務監控系統對服務質量一目瞭然；
3、服務的健康狀態的檢查自動化，在不好的時候對服務進行降級處理，實現智能化和自動化。
加入服務發現系統，架構調用如下：
2.5 Service Mesh(服務網格)
Service Mesh可以解決的問題：支持多語言，解決庫升級的麻煩。
在服務mesh之前，調用方實例通過自己內部的rpc與服務方實例進行通信，
在服務mesh之後，調用方實例通過Service Mesh proxy代理層與服務方實例進行通信；
總結：域名系統解決了需要記住複雜的數字 IP 地址的問題。
PB 類軟件庫的出現解決協議定義解析的痛點。
網關類組件解決客戶端接入以及服務器橫向擴展等一系列問題。