閒聊微服務之服務註冊中心

序言

   聚是一團火，散是漫天星，這是對微服務的最好完的解釋了。

   服務，提供什麼服務，有的叫服務中心，有的叫註冊中心，有的叫服務註冊中心，表達的都是同一個意思。

服務註冊中心

     1 爲何須要服務註冊中心

    咱們老是在談SOA，老是在談微服務，而服務註冊中心則是微服務的基礎，那麼爲何須要這個基礎。

    微服務須要將一個一體化的應用進行拆拆拆，拆成各類微小的服務，這樣有什麼好處？

    首先，便於發現服務的瓶頸，對於一個一體化的應用來講，追查每個階段的耗時太複雜了，而拆解成微服務以後，則能夠追查每一個階段的調用的耗時，能夠發現系統的性能瓶頸。

    其次，發現了性能瓶頸以後，或者發現某個應用的TPS，QPS隨着業務的增多，那麼能夠進行水平擴容，在初期階段，性能能夠接近線性增加。

    微服務，麻雀雖小，五臟俱全，團隊大了怎麼辦？那就拆，拆成小團隊進行單兵做戰，從而能大大提升效率。

    那這個和服務註冊中心有半毛錢關係，仍是有半毛錢的。你可能說這些功能其實負載均衡也能提供，不管是高可用的冗餘，仍是性能的追求，可是負載均衡僅僅是爲了冗餘，而不是爲了性能，並且最重要的區別在於，負載均衡是靜態的，而服務註冊中心則是動態，這就是爲何不使用負載均衡的緣由。

    2 服務註冊中心的名詞

    服務註冊中心主要分爲三個部分，一個部分是服務的提供者，一個部分是服務註冊中心，一個部分則是服務的消費者。

    隨着業務的發展，應用愈來愈多，每一個應用之間的交互也愈來愈多，從而爲了解決應用之間的依賴關係，從而須要使用服務註冊中心。

    在進行使用服務中心的時候，根據應用來進行劃分，有的應用可能提供多個服務，有的應用也有可能消費多個服務，RPC服務調用瞭解一下。

    在數據流程上，服務提供者啓動服務以後，會將服務註冊到服務註冊中心，而當服務消費者啓動的時候，會從服務註冊中心拉取相關的配置，放到緩存中。從本質上來講，其實也就是一個名稱解析服務，由於對於服務消費者來講，首先，從服務註冊中心根據服務名找到服務提供者的ip和端口，而後根據內部的調度機制，找到一個服務提供者訪問，獲得請求結果。

    從而，註冊中心解偶了服務提供者和服務消費者之間的關係，而且支持彈性的擴容和縮容，當你擴容的時候，只要將你的服務再次擴展一個，也就會自動註冊到註冊中心了。

    服務發現，是站在服務消費者的角度來講，能發現服務提供者的ip增多或者減小，其實這是由於服務註冊中心的主動推送的做用。

    服務註冊，是站在服務生產者的角度來講，也就是服務生產者將服務註冊到服務註冊中心。

    服務路由，主要是將服務生產者的ip緩存在本地，而後在其中使用調度算法選擇一個合適的服務提供者。

    3 從開發者的角度看

    從開發者的角度來看，在使用服務註冊中心的時候，是否須要修改代碼，從而分爲應用內和應用外。

    我不是黃蓉，我不會武功，我不是開發，我只是瞎逼逼。

    開發關心的是，我一個系統有幾個應用，幾個應用提供幾個服務，從而須要一個界面，能查看到相關的服務，例如應用名稱，服務名稱，服務提供者的數量，服務消費者提供的數量；每一個應用有幾個服務ip，端口等信息。

    服務調度的時候若是是使用wrr算法，那麼還有一個地方能設置權重，在服務進行升級的時候，爲了避免影響，應該還須要提供相關的接口，關閉服務開啓服務，這樣才能進行服務的熱升級。

    應用之間的依賴關係圖，也就是應用有哪些服務，服務之間的依賴關係是啥樣的，須要一個拓撲圖，否則，追蹤問題的時候很麻煩，並且最好還須要有埋點，從而能從每一個階段進行追蹤服務。

    3 從運維側看服務註冊中心

     運維側，主要就是解決問題，會出現哪些問題？服務未註冊成功，服務註冊超時，服務獲取超時，服務註冊中心的高可用，服務註冊的中心的擴展性。

    部署，從部署的角度看運維複雜度，例如須要消耗幾個服務器，須要多少cpu，內存，存儲。

    升級，在進行升級的時候，是否影響服務的提供，熱升級？如何作到無感升級。

    監控，須要監控哪些日誌，須要監控哪些服務，自身的服務監控，註冊的服務監控。

    健康檢查，對各類服務的上線，下線，修改，是否能及時的通知到消費者。

    高可用，是採用三節點？仍是五節點？

    在跨機房的時候，怎麼作？選擇zk仍是consul？仍是etcd？在單個機房的時候，選擇consul？考慮到CAP的什麼特性？跨機房的時候，運維複雜度怎麼衡量？怎麼取捨？

    4 註冊中心

     在使用服務註冊中心的時候，除了上面所講的服務名稱系統，其實還有一種，就是服務總線系統，其實這種和esb相似。

    服務總線系統和服務名稱系統的主要區別就是，當請求發送給服務註冊中心的時候服務中心會代替客戶端進行訪問相關的服務提供者，從而對於服務消費者來講，只要一次調用，便可完成，而對於服務名稱系統來講，須要發起兩次調用。

      哪種更好？服務總線系統更加複雜，可是有更大的靈活性，而對於服務名稱系統來講，差很少基本上要提供一個SDK，從而在升級的時候，也是麻煩，你是否須要升級客戶端，接口的兼容性也是須要考慮的。

    聚是滿天星，散是一團火，這樣感受也很酷，雖然是人走茶涼，可是可能散開的一個火種。

    服務中心的主要功能是配置和調度，若是服務中心自己是瓶頸怎麼辦？平行擴容？

    今夜的寒風將我撕碎。何以解憂，未有頭緒。