資訊專欄INFORMATION COLUMN
摘要：此文已由作者劉超授權網易云社區發布。五更加適合微服務和的設計好了，說了本身，接下來說說的理念設計，為什么這么適合微服務。相關閱讀為什么天然適合微服務為什么天然適合微服務為什么天然適合微服務文章來源網易云社區
此文已由作者劉超授權網易云社區發布。
歡迎訪問網易云社區，了解更多網易技術產品運營經驗
四、Kubernetes 本身就是微服務架構
基于上面這十個設計要點，我們再回來看 Kubernetes，會發現越看越順眼。
首先 Kubernetes 本身就是微服務的架構，雖然看起來復雜，但是容易定制化，容易橫向擴展。
如圖黑色的部分是 Kubernetes 原生的部分，而藍色的部分是網易云為了支撐大規模高并發應用而做的定制化部分。
Kubernetes 的 API Server 更像網關，提供統一的鑒權和訪問接口。
眾所周知，Kubernetes 的租戶管理相對比較弱，尤其是對于公有云場景，復雜的租戶關系的管理，我們只要定制化 API Server，對接 Keystone，就可以管理復雜的租戶關系，而不用管其他的組件。
在 Kubernetes 中幾乎所有的組件都是無狀態化的，狀態都保存在統一的 etcd 里面，這使得擴展性非常好，組件之間異步完成自己的任務，將結果放在 etcd 里面，互相不耦合。
例如圖中 pod 的創建過程，客戶端的創建僅僅是在 etcd 中生成一個記錄，而其他的組件監聽到這個事件后，也相應異步的做自己的事情，并將處理的結果同樣放在 etcd 中，同樣并不是哪一個組件遠程調用 kubelet，命令它進行容器的創建，而是發現 etcd 中，pod 被綁定到了自己這里，方才拉起。
為了在公有云中實現租戶的隔離性，我們的策略是不同的租戶，不共享節點，這就需要 Kubernetes 對于 IaaS 層有所感知，因而需要實現自己的 Controller，Kubernetes 的設計使得我們可以獨立創建自己的 Controller，而不是直接改代碼。
API-Server 作為接入層，是有自己的緩存機制的，防止所有的請求壓力直接到后端數據庫上。但是當仍然無法承載高并發請求時，瓶頸依然在后端的 etcd 存儲上，這和電商應用一摸一樣。當然能夠想到的方式也是對 etcd 進行分庫分表，不同的租戶保存在不同的 etcd 集群中。
有了 API Server 做 API 網關，后端的服務進行定制化，對于 client 和 kubelet 是透明的。
如圖是定制化的容器創建流程，由于大促和非大促期間，節點的數目相差比較大，因而不能采用事先全部創建好節點的方式，這樣會造成資源的浪費，因而中間添加了網易云自己的模塊 Controller 和 IaaS 的管理層，使得當創建容器資源不足的時候，動態調用 IaaS 的接口，動態的創建資源。這一切對于客戶端和 kubelet 無感知。
為了解決超過 3 萬個節點的規模問題，網易云需要對各個模塊進行優化，由于每個子模塊僅僅完成自己的功能，Scheduler 只管調度，Proxy 只管轉發，而非耦合在一起，因而每個組件都可以進行獨立的優化，這符合微服務中的獨立功能，獨立優化，互不影響。而且 Kubernetes 的所有組件都是 Go 開發的，更加容易一些。所以 Kubernetes 上手慢，但是一旦需要定制化，會發現更加容易。
五、Kubernetes 更加適合微服務和 DevOps 的設計
好了，說了 K8S 本身，接下來說說 K8S 的理念設計，為什么這么適合微服務。
前面微服務設計的十大模式，其中一個就是區分無狀態和有狀態，在 K8S 中，無狀態對應 deployment，有狀態對應 StatefulSet。
deployment 主要通過副本數，解決橫向擴展的問題。
而 StatefulSet 通過一致的網絡 ID，一致的存儲，順序的升級，擴展，回滾等機制，保證有狀態應用，很好地利用自己的高可用機制。因為大多數集群的高可用機制，都是可以容忍一個節點暫時掛掉的，但是不能容忍大多數節點同時掛掉。而且高可用機制雖然可以保證一個節點掛掉后回來，有一定的修復機制，但是需要知道剛才掛掉的到底是哪個節點，StatefulSet 的機制可以讓容器里面的腳本有足夠的信息，處理這些情況，實現哪怕是有狀態，也能盡快修復。
在微服務中，比較推薦使用云平臺的 PaaS，例如數據庫，消息總線，緩存等。但是配置也是非常復雜的，因為不同的環境需要連接不同的 PaaS 服務。
K8S 里面的 headless service 是可以很好地解決這個問題的，只要給外部服務創建一個 headless service，指向相應的 PaaS 服務，并且將服務名配置到應用中。由于生產和測試環境分成 Namespace，雖然配置了相同的服務名，但是不會錯誤訪問，簡化了配置。
微服務少不了服務發現，除了應用層可以使用 SpringCloud 或者 Dubbo 進行服務發現，在容器平臺層當然是用 Service了，可以實現負載均衡，自修復，自動關聯。
服務編排，本來 K8S 就是編排的標準，可以將 yml 文件放到代碼倉庫中進行管理，而通過 deployment 的副本數，可以實現彈性伸縮。
對于配置中心，K8S 提供了 configMap，可以在容器啟動的時候，將配置注入到環境變量或者 Volume 里面。但是唯一的缺點是，注入到環境變量中的配置不能動態改變了，好在 Volume 里面的可以，只要容器中的進程有 reload 機制，就可以實現配置的動態下發了。
統一日志和監控往往需要在 Node 上部署 Agent，來對日志和指標進行收集，當然每個 Node 上都有，daemonset 的設計，使得更容易實現。
當然目前最最火的 Service Mesh，可以實現更加精細化的服務治理，進行熔斷，路由，降級等策略。Service Mesh 的實現往往通過 sidecar 的方式，攔截服務的流量，進行治理。這也得力于 Pod 的理念，一個 Pod 可以有多個容器，如果當初的設計沒有 Pod，直接啟動的就是容器，會非常的不方便。
所以 K8S 的各種設計，看起來非常冗余和復雜，入門門檻比較高，但是一旦想實現真正的微服務，K8S 可以給你各種可能的組合方式。實踐過微服務的人，往往會對這一點深有體會。
六、Kubernetes 常見的使用方式
下面我們來看一下，微服務化的不同階段，Kubernetes 的使用方式。
第一階段：使用公有云虛擬機
也即沒有微服務化的階段，基本上一個進程就能搞定，兩個進程做高可用，不需要使用容器，虛擬機就非常好。
第二階段：容器作為持續集成工具
當微服務開始拆分了，如何保證拆分后功能的一致性，需要持續集成作為保證，如前面的論述，容器是非常好的持續集成工具，是解決 CI/CD 中 D 的，所以一開始用 host 網絡就可以，這樣可以保證部署方式和原來兼容。
如果想用私有云進行部署，直接部署在物理機上，在性能要求沒有很高，但是又要和其他物理機很好的通信的情況下，可以用 bridge 打平網絡的方式比較好。通過創建網橋，將物理網卡，容器網卡都連接到一個網橋上，可以實現所有的容器和物理機在同樣的一個二層網絡里面。
如果性能要求比較高，例如要部署類似緩存，則可以使用 sr-iov 網卡。
如果想實現租戶的簡單隔離，則往往使用各種 Overlay 的網絡模式，這是最常用的部署方式。圖中的數據來自網絡。Flannel，Calico 都是非常好的網絡插件，雖然 Flannel 一開始使用用戶態的模式性能不好，后來使用內核態，性能大大改善，使用 gw 模式后，和 Calico 性能相當。
網易云采用了 Kubernetes 和 IaaS 深度融合的方式，類似 AWS 的 Fargate 的模式，一方面可以使得原來使用虛擬機的用戶平滑地遷移到容器，另一方面可以實現公有云的租戶隔離。
如圖是融合的網易云容器服務的架構，這個管理 OpenStack 和 Kubernetes 的管理平臺，也是用的微服務架構，有 API 網關，熔斷限流功能，拆分成不同的服務，部署在 K8S 上的，所以處處是微服務。
網易云輕舟微服務是圍繞應用和微服務打造的一站式 PaaS 平臺，幫助用戶快速實現易接入、易運維的微服務解決方案。
相關閱讀：為什么 kubernetes 天然適合微服務 (1)
為什么 kubernetes 天然適合微服務 （2）
為什么 kubernetes 天然適合微服務 （3）
文章來源： 網易云社區
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/25290.html
摘要：此文已由作者劉超授權網易云社區發布。所以當我們評估大數據平臺牛不牛的時候，往往以單位時間內跑的任務數目以及能夠處理的數據量來衡量。的問題調度在大數據領域是核心中的核心，在容器平臺中是重要的，但不是全部。 此文已由作者劉超授權網易云社區發布。 歡迎訪問網易云社區，了解更多網易技術產品運營經驗 最近總在思考，為什么在支撐容器平臺和微服務的競爭中，Kubernetes 會取得最終的勝出，事實...
摘要：有了分布式數據庫可以使數據庫的性能可以隨著節點增加線性地增加。分布式數據庫最最下面是，是主備的，通過的內核開發能力，我們能夠實現主備切換數據零丟失，所以數據落在這個里面，是非常放心的，哪怕是掛了一個節點，切換完了以后，你的數據也是不會丟的。 此文已由作者劉超授權網易云社區發布。 歡迎訪問網易云社區，了解更多網易技術產品運營經驗 三、微服務化的十個設計要點 微服務有哪些要點呢？第一張圖是...
摘要：要玩好微服務，微服務平臺需要的不僅僅是無侵入的服務治理能力，容器測試等服務也是必要的，這也是網易云輕舟微服務的產品設計思路。 歡迎訪問網易云社區，了解更多網易技術產品運營經驗。 簡單地說，微服務架構就是以業務域或業務功能為邊界，將一個大而全的應用拆分為可以獨立開發，獨立部署，獨立測試，獨立運行的一組小的應用，并且使用輕量級，通用的機制在這組應用間進行通信。 showImg(https:...
摘要：擁有活躍的社區，在上獲得的數超過了萬，符合網易云的選擇。當然，也有一些不足，比如不能用于日志監控分布式追蹤等范圍，所以網易云也做了很多設計和優化。 分享網易云輕舟微服務選擇基于 Prometheus 開發微服務監控系統的考量： 開源 云原生 與微服務監控需求的匹配度很高 開源 Prometheus是CNCF（云原生計算基金會）旗下成熟的開源項目，而開源技術棧是網易云堅定不移的選擇，不僅...
摘要：宋體自年被開源以來，很快便成為了容器編排領域的標準。宋體年月，樂心醫療的第一個生產用集群正式上線。所以于年推出后，樂心醫療的運維團隊在開會討論之后一致決定盡快遷移到。Kubernetes 自 2014 年被 Google 開源以來，很快便成為了容器編排領域的標準。因其支持自動化部署、大規模可伸縮和容器化管理等天然優勢，已經被廣泛接納。但由于 Kubernetes 本身的復雜性，也讓很多企業的...
閱讀 1998·2021-09-30 09:53
閱讀 1841·2021-09-24 09:48
閱讀 1755·2019-08-30 14:01
閱讀 2170·2019-08-29 18:35
閱讀 1249·2019-08-26 18:27
閱讀 2979·2019-08-26 12:12
閱讀 942·2019-08-23 17:16
閱讀 931·2019-08-23 15:31
