本文主要講解了從第一代微服務架構，到以springcloud爲表明的第二代微服務架構，再到k8s爲表明的容器技術服務架構的演進過程。java
一、ICE分佈式基礎架構平臺
node
服務編排：服務編排主要有icegrid採用xml的方式進行定義服務部署拓撲，經過命令行工具一鍵發佈；linux
服務管理：icegrid中的服務運行在icebox容器中，由容器管理服務的整個生命週期，包括啓動，中止，升級等過程；web
服務註冊：服務註冊主要有iceRegistery完成，而且一主一從，防止單點故障。redis
負載均衡：採用客戶端負載均衡機制，在客戶端sdk中內嵌實現，無需編程，具備基於主機負載，輪詢等多種方式；spring
運維平臺：基於命令行和java gui的管理工具。能夠用來發布grid，升級gird。中止和重啓gird服務，以及服務內部狀態查詢。docker
在icegrid以後出現了dubbo，springcloud，motan等都是java語言體系內的微服務框架，並不支持其餘語言，跟ice相比，完備性還達不到平臺的級別，截至的目前爲止只能稱之爲框架。shell
二、dubbo和springcloud對比
編程
| 核心功能 | dubbo | springcloud |
| 開發語言 | java | java |
| 跨編程語言 | 不支持 | 不支持 |
| 服務註冊中心 | zookeeper、redis | springcloud eureka |
| 服務調用方式 | RPC | rest api |
| 服務網關 | 無 | springcloud zuul |
| 斷路器 | 不完善 | springcloud hystrix |
| 分佈式配置 | 無 | springcloud config |
| 分佈式追蹤系統 | 無 | springcloud sleuth |
| 消息總線 | 無 | springcloud bus |
| 數據流 | 無 | 基於redis、kafaka等 |
| 批量任務 | 無 | springcloud task |
從核心功能來看，SpringCloud更勝一籌，在開發過程當中只要整合SpringCloud 的子項目就能夠順利的完成各類組件的融合，特別是SpringCloud實現了服務網關zuul這是SpringCloud區別於其它框架的緣由之一，zuul採用了代理設計模式，主要功能是服務路由，可是SpringCloud中的Service全是基於HTTP的，而Dubbo卻須要經過實現各類插件來作定製，開發成本以及技術難度略高。
設計模式
可是Dubbo支持各類通訊協議，並且消費方和服務方使用長連接方式交互，通訊速度上略勝SpringCloud，若是對於系統的響應時間有嚴格要求，長連接更合適。
另外出現的motan，起步較晚，從架構設計和功能上看相似於dubbo，但知名度和市場佔有率遠遠不及dubbo。
thrift和grpc通訊效率很是高，跨語言，可是不支持分佈式和註冊中心等互聯網框架中常見功能，並且對源代碼自己有必定侵入性。
三、Kubernetes基礎架構平臺
API Server：顧名思義是用來處理 API 操做的，Kubernetes 中全部的組件都會和 API Server 進行鏈接，組件與組件之間通常不進行獨立的鏈接，都依賴於 API Server 進行消息的傳送；
Controller：是控制器，它用來完成對集羣狀態的一些管理。好比剛剛咱們提到的兩個例子之中，第一個自動對容器進行修復、第二個自動進行水平擴張，都是由 Kubernetes 中的 Controller 來進行完成的；
Scheduler：是調度器，「調度器」顧名思義就是完成調度的操做，就是咱們剛纔介紹的第一個例子中，把一個用戶提交的 Container，依據它對 CPU、對 memory 請求大小，找一臺合適的節點，進行放置；
etcd：是一個分佈式的一個存儲系統，API Server 中所須要的這些原信息都被放置在 etcd 中，etcd 自己是一個高可用系統，經過 etcd 保證整個 Kubernetes 的 Master 組件的高可用性。
Node:node是真正運行業務負載的節點，每一個業務都會以pod的形式運行，每一個pod中能夠包含一個或者多個container容器，其中pod被Deployment管理，能夠根據服務負載進行擴容、升級、回滾等操做，pod運行在kubelet上。
四、ICE和Kubernetes對比
若是對比起來看icegrid和kubernetes有極大的類似之處；
Kubernetes服務編排以yaml格式文件，ICE有grid.xml；
Kubernetes pod中的運行時容器相似於icebox；
Kubernetes node中的Service相似於icebox中的Service；
Kubernetes中的API Server至關於ICE中Registry；
Kubernetes中的命令行和界面工具相似於ICE命令行和IcegridAdmin界面。
ICE和Kubernetes的不一樣之處
負載均衡方面Kubernetes經過kube-proxy進行負載均衡，ICE經過客戶端實現負載均衡。
Kubernetes沒有實現RPC形式的通訊框架，任何協議的通訊框架都須要基於Kubernetes框架自行構建。
既然有了電信級別的框架ICE（前Corbar專家聯合打造的優秀分佈式基礎架構平臺），CNCF社區爲什麼又要勞神費力研究Kubernetes呢?
服務負載能力：首先Kubernetes中Service，經過ClusterIp進行把經此的流量調度到pod上。經過iptables實現集羣內組網，其底層是經過linux nat技術實現。傳統狀況下咱們須要部署一個負載均衡服務，須要找到各類組件，配置，可能還要修改代碼，但kubernetes的一個命令就能夠把單體服務複製成多份，在鏈接方式上跟正常鏈接單體服務沒有什麼區別。
自動化能力：Kubernetes採用狀態機模式進行設計，內部實現體現形式是控制器，一直在進行從初態到終態的判斷。其中服務自動能力主要依靠Deployment實現，Deployment首先是一個控制器，它會控制當前副本的數量跟咱們指望的數量一致，若是某臺機器宕機，Kubernetes控制器會自動選擇其餘節點進行重建副本，保證發佈過程當中，實際副本數量和指望一致；當咱們發佈完成後功能有問題，能夠回滾到以前版本以及各類灰度發佈驗證，能夠想象下，若是線上環境存在幾百個節點，依靠人肉處理，須要多大工做量。
探針是另外一個體現自動化能力的表現，目前有存活探針和就緒探針支持HTTP、TCP以及自定義shell腳本。傳統分佈式服務中，長時間運行後，節點中可能會存在殭屍服務，一般的作法是進行侵入式設計，在每一個服務中提供一個專有方法，循環調用檢測是否正常。而後經過人爲的方式處理服務故障，而kubernetes中的探針服務探測到服務不正常，能夠根據策略配置重建pod自動重啓服務，中間過程不須要人爲干預。
在存儲方面Kubernetes更是實現了動態分配，回收，對存儲的全生命週期的管理過程。
分佈式配置能力：以configmap爲例，相比於各類分佈式配置管理工具（在傳統分佈式集羣中更有優點），configmap是拆箱即用，不用單獨維護，不須要作任何源程序的邏輯修改，能夠實現分佈式配置各類功能。
五、總結
當然分佈式架構相比於單體應用要複雜不少，可是隨着服務自己的複雜度增長，單體應用由於模塊劃分不清晰常常爲修改一個很小的功能而牽一髮動全身，再加上IT行業人員流動性比較大，就形成了咱們在修改項目架構和轉型的陣痛中不斷翻轉。微服務大大增長了開發工做量並要求開發人員必需要掌握某種RPC技術，RPC在實際通訊過程當中產生的各類底層問題更是讓人難以捉摸。如今以Kubernetes爲表明的第一臺容器基礎架構出現了，旨在解決下降服務與服務之間的調用問題，讓應用更有彈性、容錯性、觀測性的基礎技術，讓應用更容易部署、管理、交付的基礎軟件、可是前期須要投入大量學習和試錯成本，固然任何技術都有兩面性，存在優勢的同時必然存在缺點，這就要根據實際狀況作出選擇了。
提早祝你們2020年：
霧霾都散去
好事都到來
逝者不可追
來者猶可期
原創不易，隨手關注或者」在看「，誠摯感謝！
推薦閱讀：
Kubernetes中如何使用ClusterDNS進行服務發現？
本文分享自微信公衆號 - 雲原生技術愛好者社區（programmer_java）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。