轉載請註明出自微信公眾號：奔跑中的蝸牛

在這個開源的世界，實際上擺在我們面前的方案有很多。很多時候連架構師都難以選擇。下面介紹三種典型的叢集架構模型。

重客戶端系

優勢：

1、註冊中心作為協調器，客戶端和服務端直連，消費者和提供者只在服務啟動時或者服務發生變化時才依賴註冊中心，其餘時間註冊中心出現任何問題，服務發生變化之前都不會影響呼叫，註冊中心壓力較小；

2、客戶端做負載均衡，生產者和消費者直連，中間無效能損耗；

3、SDK的方式，顯然易用性得到保障。

劣勢：

1、重客戶端，以SDK的方式侵入系統。如果SDK升級，會比較麻煩；

很明顯，這種模式非常普遍，由於

代理系

優勢：

1、代理上實際可以做負載均衡、容量規劃、灰度釋出等相關功能，但是像rpc、容錯等相關功能必須在客戶端來做，也就是需要SDK的支援。

2、降低連線數，如果按照每個消費者和生產者建立單鏈接計算，重客戶端模式實際上有多少個消費者就需要生產者建立多少個連結，而代理模式可以讓連線數降到只有生產者和代理的一個連結。

劣勢：

1、多一層代理，效能上有消耗

2、增加一個不穩定因素

cobar屬於這種模式，cobar和tddl都是資料庫中介軟體，這兩種模式有什麼區別呢，如果單純從資料庫中介軟體這個層面來看，我更支援

多級代理

優勢：

1、同代理模式，代理上實際可以做負載均衡、容量規劃、灰度釋出等相關功能，但是像rpc、容錯等相關功能必須在客戶端來做，也就是需要SDK的支援。

2、代理分別與生產者、消費者放在同一容器中，proxy提取了大部分SDK的功能，proxy升級對應用無影響；

3、雖然1次請求變成3次，但是真正耗時的是網路間的那次通訊，效能較一個代理要高；

劣勢：

1、複雜度變高，這讓開發、除錯、部署都變得麻煩；

2、增加了兩個不確定的點，對於穩定性來說是一個利空；

3、Proxy也需要佔用資源，對cpu、記憶體、磁碟都有消耗；

總結：

重客戶端這種模式不僅是在服務化框架中採用，很多中介軟體也採用類似的模式。侵入性本身和易用性就是相反的，而框架本身不但要起到服務化的作用，還要給開發人員提供方便，抽象通用功能，規範程式碼。或者把這些部分都扔給開發框架來做。

從KISS的原則來看，顯然重客戶端的方式更簡單、美觀；如果是PaaS平臺，提供給第三方，從侵入性角度來說，多級代理也許是個好的選擇（可以參見Kubernetes的結構）。否則你必須使用雲平臺提供的個性化SDK。如果從一個雲遷移到另一個會比較麻煩。

Kubernetes強調的是容器級別的微服務，對於這個概念並不是特別清晰，到底什麼樣的才算微服務？單純用開發人數來約定非常傻，用程式碼行數更傻，如果按照幾百行的程式碼切分一個服務出來，那架構會變得異常複雜。我覺得大多數應用都是從集中開始一點點分裂的，服務化的分裂方式大多是業務相關性和團隊規模決定的，當然如果都搞成細胞架構非常符合未來軟體發展的趨勢，只是如果切分的太小勢必帶來成本的增高，服務依賴的複雜性升高，可用性的提升必然帶來一致性的降低。如果進化到微服務，依賴關係極其複雜的情況下，每個小小的改動都需要通知所有的呼叫者。在選擇架構的時候，要謹慎選擇。切分粒度是一個需要權衡的問題。這裡內容很多，找個時間專門寫一篇。

大多數網際網路公司就算用雲平臺，大多也是使用IaaS平臺，這意味著可以使用自己的服務化框架，dubbo必須是首選。除非將來像Kubernetes這種PaaS平臺上誕生幾個非常牛逼的專案出來，引領潮流。

更多文章歡迎關注奔跑中的蝸牛，