融數(shù)數(shù)據(jù)基于Kubernetes的微服務治理和構建平臺

融數(shù)數(shù)據(jù)基于Kubernetes的微服務治理和構建平臺

DNS：A——IP地址CName——主機名PTR——與A相反SRV——DNSSRV是DNS記錄中一種，用來指定服務地址。與常見的A記錄、cname不同的是，SRV中除了記錄服務器的地址，還記錄了服務的端口，并且可以設置每個服務地址的優(yōu)先級和權重。訪問服務的時候，本地的DNSresolver從DNS服務器查詢到一個地址列表，根據(jù)優(yōu)先級和權重，從中選取一個地址作為本次請求的目標地址。

我們都知道CAP是EricBrewer提出的分布式系統(tǒng)三要素：

強一致性(Consistency)

可用性(Availability)

分區(qū)容忍性(PartitionTolerance)幾乎所有的服務發(fā)現(xiàn)和注冊方案都是CP系統(tǒng)，也就是說滿足了在同一個數(shù)據(jù)有多個副本的情況下，對于數(shù)據(jù)的更新操作達到最終的效果和操作一份數(shù)據(jù)是一樣的，但是在出現(xiàn)網(wǎng)絡分區(qū)（分區(qū)間的節(jié)點無法進行網(wǎng)絡通信）這樣的故障的時候，在節(jié)點之間恢復通信并且同步數(shù)據(jù)之前，一些節(jié)點將會無法提供服務（一些系統(tǒng)在節(jié)點丟失的情況下支持stalereads）。

服務發(fā)現(xiàn)之EtcdVSConsul

值得注意的是，分布式系統(tǒng)中的數(shù)據(jù)分為控制數(shù)據(jù)和應用數(shù)據(jù)。使用etcd的場景默認處理的數(shù)據(jù)都是控制數(shù)據(jù)，對于應用數(shù)據(jù)，只推薦數(shù)據(jù)量很小，但是更新訪問頻繁的情況。

抄自這里

************************************************************************************************網(wǎng)上找來找去都是zk和etcd的比較，和consul的比較很少，這個感覺還算靠譜，也在別的地方看到過對consul的吐槽，記錄下************************************************************************************************

導語在分布式微服務架構中，一個應用可能由一組職責單一化的服務組成。這時候就需要一個注冊服務的機制，注冊某個服務或者某個節(jié)點是可用的，還需要一個發(fā)現(xiàn)服務的機制來找到哪些服務或者哪些節(jié)點還在提供服務。在實際應用中，通常還都需要一個配置文件告訴我們一些配置信息，比如數(shù)據(jù)連接的地址，redis的地址等等。但很多時候，我們想要動態(tài)地在不修改代碼的情況下得到這些信息，并且能很好地管理它們。有了這些需求，于是發(fā)展出了一系列的開源框架，比如ZooKeeper,Etcd,Consul等等。這些框架一般會提供這樣的服務：服務注冊

主機名，端口號，版本號，或者一些環(huán)境信息。服務發(fā)現(xiàn)

可以讓客戶端拿到服務端地址。一個分布式的通用k/v存儲系統(tǒng)

基于Paxos算法或者Raft算法領導者選舉(LeaderElection)其它一些例子：

分布式鎖(Distributedlocking)

原子廣播(Atomicbroadcast)

序列號(Sequencenumbers)

…我們都知道CAP是EricBrewer提出的分布式系統(tǒng)三要素：

強一致性(Consistency)

可用性(Availability)

分區(qū)容忍性(PartitionTolerance)幾乎所有的服務發(fā)現(xiàn)和注冊方案都是CP系統(tǒng)，也就是說滿足了在同一個數(shù)據(jù)有多個副本的情況下，對于數(shù)據(jù)的更新操作達到最終的效果和操作一份數(shù)據(jù)是一樣的，但是在出現(xiàn)網(wǎng)絡分區(qū)（分區(qū)間的節(jié)點無法進行網(wǎng)絡通信）這樣的故障的時候，在節(jié)點之間恢復通信并且同步數(shù)據(jù)之前，一些節(jié)點將會無法提供服務（一些系統(tǒng)在節(jié)點丟失的情況下支持stalereads）。ZooKeeper作為這類框架中歷史最悠久的之一，是由Java編寫。Java在許多方面非常偉大，然而對于這種類型的工作還是顯得有些沉重，也正因為其復雜性和對新鮮事物的向往，我們第一時間就放棄了選擇它。本文將從協(xié)議和應用層來比較Etcd和Consul，并最終給出了筆者的偏好。EtcdEtcd是一個使用go語言寫的分布式k/v存儲系統(tǒng)。考慮到它是coreos公司的項目，以及在GitHub上的star數(shù)量(9000+)，Google著名的容器管理工具Kuberbetes就是基于Etcd的。我們最先考慮的就是它。在介紹Etcd之前，我們需要了解一些基本的概念。我們知道在單臺服務器單個進程中維護一個狀態(tài)是很容易的，讀寫的時候不會產生沖突。即便在多進程或者多線程環(huán)境中，使用鎖機制或者協(xié)程（coroutine）也可以讓讀寫有序地進行。但是在分布式系統(tǒng)中，情況就會復雜很多，服務器可能崩潰，節(jié)點間的機器可能網(wǎng)絡不通等等。所以一致性協(xié)議就是用來在一個集群里的多臺機器中維護一個一致的狀態(tài)。很多的分布式系統(tǒng)都會采用Paxos協(xié)議，但是Paxos協(xié)議難以理解，并且在實際實現(xiàn)中差別比較大。所以Etcd選擇了Raft作為它的一致性協(xié)議。Raft是DiegoOngaro和JohnOusterhout在‘InSearchofanUnderstandableConsensusAlgorithm’中提出的。它在犧牲很少可用性，達到相似功能的情況下，對Paxos做了很大的優(yōu)化，并且比Paxos簡單易懂很多。它主要集中在解決兩個問題：領導者選舉(LeaderElection)

Raft先通過領導選舉選出一個Leader，后續(xù)的一致性維護都由Leader來完成，這就簡化了一致性的問題。Raft會保證一個時間下只會有一個Leader，并且在超過一半節(jié)點投票的情況下才會被選為Leader。當Leader掛掉的時候，新的Leader將會被選出來。日志復制(LogReplication)

為了維護狀態(tài)，系統(tǒng)會記錄下來所有的操作命令日志。Leader在收到客戶端操作命令后，會追加到日志的尾部。然后Leader會向集群里所有其它節(jié)點發(fā)送AppendEntriesRPC請求，每個節(jié)點都通過兩階段提交來復制命令，這保證了大部分的節(jié)點都能完成。在實際的應用中，一般Etcd集群以5個或者7個為宜，可以忍受2個或者3個節(jié)點掛掉，為什么不是越多越好呢？是出于性能的考慮，因為節(jié)點多了以后，日志的復制會導致CPU和網(wǎng)絡都出現(xiàn)瓶頸。Etcd的API比較簡單，可以對一個目錄或者一個key進行GET，PUT，DELETE操作，是基于HTTP的。Etcd提供watch某個目錄或者某個key的功能，客戶端和Etcd集群之間保持著長連接(longpolling)?；谶@個長連接，一旦數(shù)據(jù)發(fā)生改變，客戶端馬上就會收到通知，并且返回的結果是改變后的值和改變前的值，這一點在實際應用中會很有用（這也是后面的Consul的槽點之一）。Etcd的watch和在一般情況下不會漏掉任何的變更。因為Etcd不僅存儲了當前的鍵值對，還存儲了最近的變更記錄，所以如果一個落后于當前狀態(tài)的watch還是可以通過遍歷歷史變更記錄來獲取到所有的更新。Etcd還支持CompareAndSwap這個原子操作，首先對一個key進行值比較，只有結果一致才會進行下一步的賦值操作。利用這個特性就像利用x86的CAS實現(xiàn)鎖一樣可以實現(xiàn)分布式鎖。在Etcd中有個proxy的概念，它其實是個轉發(fā)服務器，啟動的時候需要指定集群的地址，然后就可以轉發(fā)客戶端的請求到集群，它本身不存儲數(shù)據(jù)。一般來說，在每個服務節(jié)點都會啟動一個proxy，所以這個proxy也是一個本地proxy，這樣服務節(jié)點就不需要知道Etcd集群的具體地址，只需要請求本地proxy。之前提到過一個k/v系統(tǒng)還應該支持leaderelection，Etcd可以通過TTL(timetolive)key來實現(xiàn)。ConsulConsul和Etcd一樣也有兩種節(jié)點，一種叫client(和Etcd的proxy一樣)只負責轉發(fā)請求，另一種是server，是真正存儲和處理事務的節(jié)點。Consul使用基于Serf實現(xiàn)的gossip協(xié)議來管理從屬關系，失敗檢測，事件廣播等等。gossip協(xié)議是一個神奇的一致性協(xié)議，之所以取名叫gossip是因為這個協(xié)議是模擬人類中傳播謠言的行為而來。要傳播謠言就要有種子節(jié)點，種子節(jié)點每秒都會隨機向其它節(jié)點發(fā)送自己所擁有的節(jié)點列表，以及需要傳播的消息。任何新加入的節(jié)點，就在這種傳播方式下很快地被全網(wǎng)所知道。這個協(xié)議的神奇就在于它從設計開始就沒想要信息一定要傳遞給所有的節(jié)點，但是隨著時間的增長，在最終的某一時刻，全網(wǎng)會得到相同的信息。當然這個時刻可能僅僅存在于理論，永遠不可達。Consul使用了兩個不同的gossippool，分別叫做LAN和WAN，這是因為Consul原生支持多數(shù)據(jù)中心。在一個數(shù)據(jù)中心內部，LANgossippool包含了這個數(shù)據(jù)中心所有的節(jié)點，包括proxy和servers。WANpool是全局唯一的，所有數(shù)據(jù)中心的servers都在這個pool中。這兩個pool的區(qū)別就是LAN處理的是數(shù)據(jù)中心內部的失敗檢測，事件廣播等等，而WAN關心的是跨數(shù)據(jù)中心的。除了gossip協(xié)議之外，Consul還使用了Raft協(xié)議來進行l(wèi)eaderelection，選出leader之后復制日志的過程和Etcd基本一致?；氐綉脤用嫔蟻碚f，Consul更像是一個fullstack的解決方案，它不僅提供了一致性k/v存儲，還封裝了服務發(fā)現(xiàn)，健康檢查，內置了DNSserver等等。這看上去非常美好，簡直可以開箱即用。于是，我們初步選定了Consul作為我們的服務發(fā)現(xiàn)和動態(tài)配置的框架。但現(xiàn)實往往是冰冷的，在深入研究它的API之后發(fā)現(xiàn)了比較多的坑，可能設計者有他自己的考慮。在使用獲取所有services的API的時候返回的只是所有服務的名字和tag，如果想要每個服務的具體信息，你還需要挨個去請求。這在客戶端就會十分不方便，因為在筆者看來，獲取所有服務的列表以及具體信息應該是一個很常見的需求，并且請求的次數(shù)越少越好。如果watch服務是否有變化，當值發(fā)生改變的時候，返回的結果居然是相當于重新讀取所有services，沒有能夠體現(xiàn)出服務信息的變化，這會導致客戶端很難進行更新操作。健康檢查是Consul的內置功能，在注冊一個服務的時候可以加上自定義的健康檢查，這聽上去很不錯。但是如果你忘記給你某個服務加上健康檢查，那它在各種API的返回結果中變得難以預料。

…結語在折騰了數(shù)天之后，最終我們決定回歸Etcd，事實證明這個決定是正確的。我們基于Etcd實現(xiàn)了穩(wěn)定的服務發(fā)現(xiàn)和動態(tài)配置功能，當然還有一些比較細節(jié)的問題沒有在文中闡述，歡迎一起探討。

傳輸層安全(TLS)是SSL的繼承協(xié)議。TLS是SSL的升級版。其工作方式與SSL極為相似，都是通過加密來保護數(shù)據(jù)和信息的傳輸。盡管SSL的應用仍然非常廣泛，在業(yè)內這兩個術語通?？梢曰Q使用。

隧道協(xié)議（TunnelingProtocol）是一類網(wǎng)絡協(xié)議，它是一種數(shù)據(jù)包封裝技術，它是將原始IP包（其報頭包含原始發(fā)送者和最終目的地）封裝在另一個數(shù)據(jù)包（稱為封裝的IP包）的數(shù)據(jù)凈荷中進行傳輸。使用隧道的原因是在不兼容的網(wǎng)絡上傳輸數(shù)據(jù)，或在不安全網(wǎng)絡上提供一個安全路徑。隧道協(xié)議通常（但并非總是）在一個比負載協(xié)議還高的層級，或同一層。---------------------

備注：說白了，通過網(wǎng)絡隧道技術，使隧道兩端的網(wǎng)絡組合成一個更大的內部網(wǎng)絡。

終止協(xié)議意味著客戶端使用期望的協(xié)議連接代理服務器，比如TLS或HTTP/2，然后代理服務器再去連接應用服務器、數(shù)據(jù)庫服務器等，但不需要使用相同的協(xié)議，如下圖所示。/2015-11-13_56455e89a4a1f.png

使用獨立的服務器終止協(xié)議意味著使用多服務器架構。多服務器可能是多個物理服務器、多個虛擬服務器，或者AWS這樣的云環(huán)境中的多個虛擬服務器實例。多服務器就比單服務器復雜，或者比應用服務器/數(shù)據(jù)庫服務器的組合復雜。不過，多服務器架構有很多好處，而且很多流量大的網(wǎng)站也必須用這種架構。配置了服務器或者虛擬服務器之后，很多事情都成為可能。新服務器可以分擔其他服務器的負載，可用于負載平衡、靜態(tài)文件緩存和其他用途。另外，也可以讓添加和替換應用服務器或其他服務器更容易。NGINX和NGINXPlus經常被用來終止TLS和HTTP/2協(xié)議、負載平衡。已有環(huán)境不必改動，除非要把NGINX服務器挪到前端。

Service實現(xiàn)了基于iptables的分布式負載均衡iptables是Linux防火墻工作在用戶空間的管理工具，是netfilter/iptablesIP信息包過濾系統(tǒng)是一部分，用來設置、維護和檢查Linux內核的IP數(shù)據(jù)包過濾規(guī)則。iptables可以檢測、修改、轉發(fā)、重定向和丟棄IP數(shù)據(jù)包。其代碼已經內置于內核中，并且按照不同的目的被組織成表（table）的集合。表由一組預先定義的鏈(chain)組成，鏈包含遍歷順序規(guī)則。每一條規(guī)則包含條件匹配和相應的動作（稱為目標），如果條件匹配為真，該動作會被執(zhí)行。

谷歌計算引擎(GCE)

融數(shù)數(shù)據(jù)基于Kubernetes的微服務治理和構建平臺.pdf

第一代監(jiān)控：Zipkin+BraveDapper：小型ORM之王

pinpoint分布式性能監(jiān)控工具(docker安裝)在做性能壓測的時候，你是不是有只能看到測試報告？在做性能壓測的時候，你是不是想知道每一個方法執(zhí)行了多長時間？Pinpoint幾乎可以幫助你查看你想看到的每一個細節(jié)。

Pinpoint是什么？Pinpoint是一款全鏈路分析工具，提供了無侵入式的調用鏈監(jiān)控、方法執(zhí)行詳情查看、應用狀態(tài)信息監(jiān)控等功能?；贕oogleDapper論文進行的實現(xiàn)，與另一款開源的全鏈路分析工具Zipkin類似，但相比Zipkin提供了無侵入式、代碼維度的監(jiān)控等更多的特性。Pinpoint支持的功能比較豐富，可以支持如下幾種功能：服務拓撲圖：對整個系統(tǒng)中應用的調用關系進行了可視化的展示，單擊某個服務節(jié)點，可以顯示該節(jié)點的詳細信息，比如當前節(jié)點狀態(tài)、請求數(shù)量等實時活躍線程圖：監(jiān)控應用內活躍線程的執(zhí)行情況，對應用的線程執(zhí)行性能可以有比較直觀的了解請求響應散點圖：以時間維度進行請求計數(shù)和響應時間的展示，拖過拖動圖表可以選擇對應的請求查看執(zhí)行的詳細情況請求調用棧查看：對分布式環(huán)境中每個請求提供了代碼維度的可見性，可以在頁面中查看請求針對到代碼維度的執(zhí)行詳情，幫助查找請求的瓶頸和故障原因。應用狀態(tài)、機器狀態(tài)檢查：通過這個功能可以查看相關應用程序的其他的一些詳細信息，比如CPU使用情況，內存狀態(tài)、垃圾收集狀態(tài)，TPS和JVM信息等參數(shù)。Java在1.5引入java.lang.instrument，你可以由此實現(xiàn)一個Java

agent,通過此agent來修改類的字節(jié)碼即改變一個類。

Pinpoint是一個分析大型分布式系統(tǒng)的平臺，提供解決方案來處理海量跟蹤數(shù)據(jù)。

Pinpoint,2012年七月開始開發(fā)，在2015年1月作為一個開源項目啟動,是一個為大型分布式系統(tǒng)服務的n層架構跟蹤平臺。Pinpoint的特點如下:分布式事務跟蹤，跟蹤跨分布式應用的消息自動檢測應用拓撲，幫助你搞清楚應用的架構水平擴展以便支持大規(guī)模服務器集群提供代碼級別的可見性以便輕松定位失敗點和瓶頸使用字節(jié)碼增強技術，添加新功能而無需修改代碼

無法識別從Node1發(fā)送的第N個消息和Node2接收到的N'消息之間的關系——Googledapper實現(xiàn)了一個簡單的解決方案來解決這個問題。這個解決方案通過在發(fā)送消息時添加應用級別的標簽作為消息之間的關聯(lián)。例如，在HTTP請求中的HTTPheader中為消息添加一個標簽信息并使用這個標簽跟蹤消息。

Pinpoint中的數(shù)據(jù)結構Pinpoint中，核心數(shù)據(jù)結構由Span,Trace,和TraceId組成。Span:RPC(遠程過程調用/remoteprocedurecall)跟蹤的基本單元;當一個RPC調用到達時指示工作已經處理完成并包含跟蹤數(shù)據(jù)。為了確保代碼級別的可見性，Span擁有帶SpanEvent標簽的子結構作為數(shù)據(jù)結構。每個Span包含一個TraceId。Trace:多個Span的集合;由關聯(lián)的RPC(Spans)組成.在同一個trace中的span共享相同的TransactionId。Trace通過SpanId和ParentSpanId整理為繼承樹結構.TraceId:由TransactionId,SpanId,和ParentSpanId組成的key的集合.TransactionId指明消息ID，而SpanId和ParentSpanId表示RPC的父-子關系。TransactionId(TxId):在分布式系統(tǒng)間單個事務發(fā)送/接收的消息的ID;必須跨整個服務器集群做到全局唯一.SpanId:當收到RPC消息時處理的工作的ID;在RPC請求到達節(jié)點時生成。ParentSpanId(pSpanId):發(fā)起RPC調用的父span的SpanId.如果節(jié)點是事務的起點，這里將沒有父span-對于這種情況，使用值-1來表示這個span是事務的根span。GoogleDapper和NAVERPinpoint在術語上的不同Pinpoint中的術語"TransactionId"和googledapper中的術語"TraceId"有相同的含義。而Pinpoint中的術語"TraceId"引用到多個key的集合。

作者：小清新同學

鏈接：/p/a803571cd570

來源：簡書

簡書著作權歸作者所有，任何形式的轉載都請聯(lián)系作者獲得授權并注明出處。Dapper和

Zipkin,Twitter的一個分布式系統(tǒng)跟蹤平臺,生成隨機TraceIds(Pinpoint是TransactionIds)并將沖突情況視為正常。然而,在Pinpiont中我們想避免沖突的可能，因此實現(xiàn)了上面描述的系統(tǒng)。有兩種選擇：一是數(shù)據(jù)量小但是沖突的可能性高，二是數(shù)據(jù)量大但是沖突的可能性低。我們選擇了第二種。

AgentId：64位長度整型

可能有更好的方式來處理transaction。我們起先有一個想法，通過中央key服務器來生成key。如果實現(xiàn)這個模式，可能導致性能問題和網(wǎng)絡錯誤。因此，大量生成key被考慮作為備選。后面這個方法可能被開發(fā)?，F(xiàn)在采用簡單方法。在pinpoint中，TransactionId被當成可變數(shù)據(jù)來對待。

使用字節(jié)碼增強技術，我們就不必擔心暴露跟蹤API而可以持續(xù)改進設計，不用考慮依賴關系?！褪强梢韵笿B變了撒

針對PinPoint的擴展和改造：-通信機制異步化調整；-探針引導程序premain改造；-gRPC探針；

DDD領域驅動／CQRS讀寫分離／ES事件溯源這些前沿的時髦的技術理念匯聚在一次，落地到一套完整實現(xiàn)方案。這就是Axon

Command執(zhí)行過程：Command通過mandhandling.CommandBus分發(fā)，其中DistributedCommandBus實現(xiàn)了分布式的派發(fā)，它可以適配SpringCloud.主要邏輯是通過

AggregateIdentifier做一致性HASH。確保次對同一個聚合根發(fā)到同一臺機器，這樣保證了緩存的命中。Aggregate本質上在應用內緩存了當前狀態(tài)，如果該服務宕機。另一臺機器會通過事件溯源重新構造出當前狀態(tài)。Command的事務處理：Axon通過UnitofWork控制一致性，其中嵌入了JDBC事務。并且在回滾時會清除Aggregate緩存，下次會重新加載。當然對于遠程的子事務無法保證一致性。這是個大的隱患Saga最終一致性，補償機制。Saga的理念沒問題，當是實現(xiàn)起來問題很大。一個是每個command都要創(chuàng)建event非常繁瑣，并且saga來來回回非常多另一個是沒有考慮到冪等，本地宕機，狀態(tài)，分布事務等細節(jié)的處理。自己實現(xiàn)也不靈活確保分布式事務一致性是個非常繁瑣的事情，請參考轉賬交易這件小事，是如何被程序員玩壞的.說說其他實現(xiàn)困難的情況如果Aggregate存在繼承關系，或者實現(xiàn)一些通用的行為接口。框架并不支持無法實現(xiàn)延遲觸發(fā)的功能對大量聚合實現(xiàn)批量操作不太容易幾乎所有的操作都要靠command觸發(fā)，然后轉成event,非常繁瑣。取其思想，尋找替代在交易中的訂單模型，本質上就是ES中的Event.賬戶余額是用訂單累加出來的。只不過訂單不止記錄事件。還用來記錄更新審核狀態(tài)，系統(tǒng)狀態(tài)，事務狀態(tài)等，不那么純粹。通過訂單回溯賬戶狀態(tài)是個人工過程而不是自動的。在這方面，Axon對事件的存儲采用統(tǒng)一的表，事件序列化到表中，并不有利于數(shù)據(jù)庫的查看。需要額外的記錄一個查詢視圖快照模型也在交易對賬中有所體現(xiàn)。每日對賬后生成當日的一個快照，第二天的交易從快照開始累計Command模型配合只insert沒有update的操作，可以在高并發(fā)下實現(xiàn)無鎖處理。這個可以通過Kafka?；蛘邤?shù)據(jù)庫先插入，后異步讀取處理的方式來實現(xiàn)。充血模型是Axon的一個特色。不過并不難實現(xiàn)。通過自定義一個SpringCloudLoadBalancerRule實現(xiàn)哈希一致也可以實現(xiàn)。另外傳統(tǒng)的失血模型使用無狀態(tài)服務更簡單，它可以在數(shù)據(jù)庫層面通過一致性hash來存儲數(shù)據(jù)，比如mongodb。對于訂單這樣的單一記錄低頻操作完全可以處理。對于同一記錄的高頻處理Axon也是有其優(yōu)勢的，不過Akka可能也是不錯的選擇Saga異常難寫，在網(wǎng)絡異常，冪等，重試方面并不友好總結：DDD領域驅動／CQRS讀寫分離／ES事件溯源，這些思想都很棒，但是并不用拘泥于特定的實現(xiàn)。Axon對于學習這些概念具有非常大的幫助，但是在實踐的過程中并不高效、靈活

作者：黃大海

鏈接：/p/4a7854e4b8f2

來源：簡書

簡書著作權歸作者所有，任何形式的轉載都請聯(lián)系作者獲得授權并注明出處。

Reveno是一個全新的無鎖事務處理框架，它支持JVM平臺，并基于CQRS及事件溯源模式實現(xiàn)。雖然它只是一個簡單而強大的工具，但在性能方面也毫不遜色。所有事務都被持久化為只讀的日志，并且可以通過按順序重演事件的方式恢復領域模型的最新狀態(tài)。所有的運行時操作都是在內存中執(zhí)行的，從而使其吞吐量可達到每秒種幾百萬次事務的數(shù)量級，平均延遲時間則限制在微秒級。雖然Reveno的功能如此強大，但它仍然是一個通用目的的框架，涵蓋了大量不同種類的用例，并提供了豐富的引擎配置選項。舉例來說，你可以調整它的持久性配置，在極其隨意（為了提高系統(tǒng)吞吐量）與高度受限（對于數(shù)據(jù)丟失的情況具有較低的容忍度）之間進行選擇。對于不同的用例來說，其需求也是千差萬別的。作為一個通用框架，它需要考慮所有不同的可能性。在本文中，我將通過示例為讀者展現(xiàn)如何使用Reveno框架開發(fā)一個簡單的交易系統(tǒng)。首先讓我們來了解一下Reveno如何處理你的領域模型。作為一個基于CQRS的框架，Reveno會將你的領域切分為事務模型與查詢模型。對這兩個模型的定義沒有任何限制，你無需使用任何強制性的注解、基類，甚至不需要實現(xiàn)Serializable接口，只需使用最簡單的POJO就可以完成任務。沒有任何一種單一的途徑能夠應對所有不同的用例，因此應用程序的設計者需要決定如何處理事務模型的回滾操作。Reveno為實現(xiàn)模型對象提供了兩種主要方式：可變與不可變模型。這兩種方式各有不同的底層處理機制，并且各有其優(yōu)缺點。在Java中，不可變對象的開銷很低，并且無需進行同步操作，這種方式目前非常流行。Reveno能夠非常高效地處理不可變對象，但每種使用不可變類型的領域都會產生額外的垃圾對象，Reveno也不例外。因此，如果你能夠接受一些額外的GC開銷，那么就應當將這種方式作為默認的選擇。反之，如果使用可變模型，那么在進行事務運行時，就要為已使用的對象生成額外的序列化快照，而這將影響到你的性能。幸運的是，如果你堅持使用可變模型，并且仍需要保證性能的最大化及GC影響的最小化，那么你可以選擇一種額外的可變模型特性，“補償行為”（CompensatingActions）。簡單來說，補償行為是指在實現(xiàn)常規(guī)的事務處理函數(shù)時，一并實現(xiàn)的一種手動回滾行為。如果讀者想了解這方面的更多細節(jié)，請參考Reveno的官方文檔頁面。

Kubernetes

的核心概念講解入門Kubernetes

是非常困難的，因為這會涉及到許多的概念和新理念，本文以圖文并茂的形式總結了Kubernetes

中的核心概念。

它本不必如此困難？掌握Kubernetes

是非常困難的，因為互聯(lián)網(wǎng)上有如此多的信息，有時候很難找到理解Kubernetes

的“核心”信息，當我們看到

kubernetes.io

站點上概念頁面和文檔如此密集時更會如此。在本文中，我們將會探索Kubernetes

的核心概念，以便于獲取關于它的基礎知識，這樣我們就可以一起揭開Kubernetes

的神秘面紗。

什么是Kubernetes？Kubernetes

提供了基礎設置和構造，幫助我們的團隊構建適用于開發(fā)和部署的可用平臺。用戶可以通過圖形化的用戶界面以及命令式和聲明式命令行接口管理Kubernetes

集群，Kubernetes

旨在管理容器化應用程序和服務的整個生命周期。借助Kubernetes，我們可以擴展和收縮應用程序、執(zhí)行滾動部署并管理由哪些服務處理特定的請求。它還提供了一個可擴展的開發(fā)框架，允許我們的團隊擴展核心的Kubernetes

原語（primitive）以滿足個性化的需求。同時，它還支持創(chuàng)建自己的概念。但是，與大多數(shù)框架一樣，它的缺點之一是缺少許多現(xiàn)成的功能，無法被視為交鑰匙（turn-key）解決方案。在標準發(fā)行版中，它不包含服務如何相互通信的方法（甚至不包含網(wǎng)絡組件!），因此存在其他的發(fā)行版，另外我們也可以構建自己的版本。容器容器是獨立、可執(zhí)行的軟件，它包含了運行所需的所有內容，比如代碼、庫和所有的外部依賴。它會確保運行的內容是完全相同的，即便是位于不同的環(huán)境中也是如此。這是通過將要運行的代碼與它的運行上下文隔離開實現(xiàn)的。在Linux

中，這是通過使用名為cgroups

的API

來分割Linux

內核的一個子集來實現(xiàn)的。這種方式提供了與操作系統(tǒng)的高度隔離，但不會帶來像虛擬化環(huán)境（如VMWare、KVM

等）那樣的性能損耗。

Podpod

是Kubernetes

中最基本的對象。pod

是容器的集合，它們共享存儲和網(wǎng)絡，并且具備如何運行它們的規(guī)范。每個pod

會分配自己的IP

地址。pod

中的容器會共享這個IP

地址、端口空間，并且能夠使用localhost

實現(xiàn)彼此查找。pod

應該被視為短暫存活的原子單元。

Replicaset根據(jù)給定的模板，replicaset

可以運行n

個pod。replicaset

并不會直接使用，但是需要理解這種資源，因為在Kubernetes

構建應用的時候，它是基礎的構建塊。（按照指令）replicaset

可以按需擴展和收縮pod

的數(shù)量。

Service因為pod

是短期存活的（replicaset

通過擴展和收縮pod

的數(shù)量實現(xiàn)這一點），那么這就帶來了一個問題，現(xiàn)在，除非使用非常復雜的邏輯，否則我們幾乎不可能引用單個pod

以便于跟蹤拓撲結構的變化。Service

通過在pod

之上提供抽象來解決這個問題，它提供了一個可尋址的方法來與pod

進行通信。Service

操作的是OSI

模型之中的“第4

層”（IP

之上的TCP/UDP）。

DeploymentDeployment

管理replicaset，可以在應用的不同版本間執(zhí)行滾動更新。這是最常用的資源類型，它通過一個接口提供了對replicaset

和pod

的抽象。

在更新Deployment

的時候，換句話說，也就是部署應用的新版本，Deployment

控制器會創(chuàng)建一個新的replicaset，并管理新版本替換舊版本的滾動更新。

在Kubernetes1.11

版本中，Deployment

目前不會自動處理回滾。ConfigMap設計良好的應用應該遵循十二要素應用宣言，應用的配置應該保存到“環(huán)境”中。盡管現(xiàn)在通用的安全實踐指出，在環(huán)境中存儲配置可能會導致私密的意外泄漏，因為一些應用程序在失敗時會暴露了它們的環(huán)境信息，但是無論如何，如果配置隨環(huán)境（開發(fā)、staging、生產）而變化的話，那么就應該將它們與要構建的應用分開進行存儲。ConfigMaps

允許將配置文件作為環(huán)境變量或文件系統(tǒng)掛載到Pod

中，從而解決了這個問題。

SecretSecret

與ConfigMap

非常類似，顧名思義，它們對應的是“Secret”信息。

DaemonsetDaemonset

會確保所有的節(jié)點都運行特定的Pod。如果要在所有節(jié)點上運行像日志代理（如fluentd）這樣的內容的話，這是非常有用的。

它還能夠通過使用Taints

忽略特定的節(jié)點。Kubernetes之Taints與Tolerations污點和容忍作者：Flywithmeto

2018-04-10

來源：51CTO

NodeAffinity節(jié)點親和性，是Pod上定義的一種屬性，使Pod能夠按我們的要求調度到某個Node上，而Taints則恰恰相反，它可以讓Node拒絕運行Pod，甚至驅逐Pod。

Taints(污點)是Node的一個屬性，設置了Taints(污點)后，因為有了污點，所以Kubernetes是不會將Pod調度到這個Node上的，

于是Kubernetes就給Pod設置了個屬性Tolerations(容忍)，只要Pod能夠容忍Node上的污點，那么Kubernetes就會忽略Node上的污點，就能夠(不是必須)把Pod調度過去。

因此

Taints(污點)通常與Tolerations(容忍)配合使用。

Ingress在大多數(shù)情況下，Service

和Pod

的IP

地址只能在Kubernetes

集群中進行訪問。Service

是與互聯(lián)網(wǎng)流量隔離的。“Ingress

是一組規(guī)則集合，它允許入站的連接訪問集群Service?！彼梢杂糜谪撦d平衡、終止TLS、為外部提供可路由的URL

等等。Ingress

只是另外一種Kubernetes

資源，但是，在大多數(shù)情況下,

它需要有一個Ingress

控制器，如Nginx

或Tr?fik

等。Kubernetes

是一個自動化容器編排平臺，能夠允許應用程序在大型平臺上大規(guī)模運行，這些平臺可以包含不同處理器體系結構和操作系統(tǒng)的組合，這完全由實現(xiàn)者決定。借助這些核心概念，Kubernetes

可以將Pod

安排到適當?shù)墓?jié)點上，以確保Pod

的最大密度，這會由Kubernetes

實現(xiàn)的多種算法來控制，比如BinPacking，從而實現(xiàn)更高的硬件利用率。參考資料：[1]

/google-cloud/kubernetes-configmaps-and-secrets-68d061f7ab5b[2]

/google-cloud/kubernetes-configmaps-and-secrets-part-2-3dc37111f0dc[3]

https://kubernetes.io/docs/concepts/configuration/secret/[4]

https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/本文最初發(fā)表于

云原生計算基金會

官方博客，由InfoQ

中文站翻譯分享。KubernetesGitBook

https://kubernetes.feisky.xyz/he-xin-yuan-li/architecture

Kubernetes提供了兩種探針（Probe，支持exec、tcp和http方式）來探測容器的狀態(tài)：Kubelet使用livenessprobe（存活探針）來確定何時重啟容器。例如，當應用程序處于運行狀態(tài)但無法做進一步操作，liveness探針將捕獲到deadlock，重啟處于該狀態(tài)下的容器，使應用程序在存在bug的情況下依然能夠繼續(xù)運行下去（誰的程序還沒幾個bug呢）。Kubelet使用readinessprobe（就緒探針）來確定容器是否已經就緒可以接受流量。只有當Pod中的容器都處于就緒狀態(tài)時kubelet才會認定該Pod處于就緒狀態(tài)。該信號的作用是控制哪些Pod應該作為service的后端。如果Pod處于非就緒狀態(tài)，那么它們將會被從service的loadbalancer中移除。

一個Kubernetes集群由分布式存儲

etcd、控制節(jié)點controller以及服務節(jié)點Node組成。

Play-with-k8s提供了一個免費的k8s體驗環(huán)境K8splayground

K8s借鑒了Borg->Omega的設計理念（谷歌），比如Pod、Service、Labels和單Pod單IP等。容器的資源隔離特性使得谷歌的資源使用率遠遠高出業(yè)界同行。例如，Borg使用容器將對延遲敏感、面向用戶的任務和批量任務放在相通的物理機上，并會為它們預留更多的資源，這樣可以解決loadspikes、fail-over等問題。容器提供的資源管理工具使這些得以實現(xiàn)，穩(wěn)定的內核層面的資源隔離也使進程之間不互相干擾。我們通過在研發(fā)Borg的同時加強Linux容器的方式來獲得成功。然而，隔離并不是完美的，容器在內核操作系統(tǒng)不能管理的資源隔離方面鞭長莫及，比如level3processorcaches、內存帶寬、以及容器需要被一個額外的安全層支持以抵抗云端的各種惡意攻擊。

Kubernetes主要由以下幾個核心組件組成：etcd保存了整個集群的狀態(tài)；kube-apiserver提供了資源操作的唯一入口，并提供認證、授權、訪問控制、API注冊和發(fā)現(xiàn)等機制；kube-controller-manager負責維護集群的狀態(tài)，比如故障檢測、自動擴展、滾動更新等；kube-scheduler負責資源的調度，按照預定的調度策略將Pod調度到相應的機器上；kubelet負責維持容器的生命周期，同時也負責Volume（CVI）和網(wǎng)絡（CNI）的管理；Containerruntime負責鏡像管理以及Pod和容器的真正運行（CRI），默認的容器運行時為Docker；kube-proxy負責為Service提供cluster內部的服務發(fā)現(xiàn)和負載均衡；除了核心組件，還有一些推薦的Add-ons：kube-dns負責為整個集群提供DNS服務IngressController為服務提供外網(wǎng)入口Heapster提供資源監(jiān)控Dashboard提供GUIFederation提供跨可用區(qū)的集群Fluentd-elasticsearch提供集群日志采集、存儲與查詢分層架構：Kubernetes設計理念和功能其實就是一個類似Linux的分層架構，如下圖所示

核心層：Kubernetes最核心的功能，對外提供API構建高層的應用，對內提供插件式應用執(zhí)行環(huán)境應用層：部署（無狀態(tài)應用、有狀態(tài)應用、批處理任務、集群應用等）和路由（服務發(fā)現(xiàn)、DNS解析等）管理層：系統(tǒng)度量（如基礎設施、容器和網(wǎng)絡的度量），自動化（如自動擴展、動態(tài)Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）——（k8s實踐利用storageclass實現(xiàn)pvc的動態(tài)provision(volume使用cephrbd)）——存儲(Storage)是運行有狀態(tài)容器的關鍵要素，Kubernetes提供了強大的原語來管理存儲。動態(tài)卷配置(Dynamicprovisioning)是Kubernetes的獨有功能，它可以根據(jù)需要動態(tài)的創(chuàng)建存儲卷。在動態(tài)配置之前，集群管理員必須手動調用云/存儲服務提供商的接口來配置新的存儲卷，然后創(chuàng)建PersistentVolume對象以在Kubernetes中表示和使用他們。通過動態(tài)配置，可以實現(xiàn)兩個步驟的自動化，無須集群管理員預先配置存儲資源，而是使用StorageClass對象制定的供應商來動態(tài)配置存儲資源，具體請參考用戶指南）。StorageClass本質上是為底層存儲提供者描繪了藍圖，以及各種參數(shù)，例如磁盤類型（例如固態(tài)和標準磁盤）?！猀uotaResourceQuotas資源配額（ResourceQuotas）是用來限制用戶資源用量的一種機制。它的工作原理為資源配額應用在Namespace上，并且每個Namespace最多只能有一個

ResourceQuota

對象開啟計算資源配額后，創(chuàng)建容器時必須配置計算資源請求或限制（也可以用

LimitRange

設置默認值）用戶超額后禁止創(chuàng)建新的資源開啟資源配額功能首先，在APIServer啟動時配置準入控制

--admission-control=ResourceQuota然后，在namespace中創(chuàng)建一個

ResourceQuota

對象資源配額的類型計算資源，包括cpu和memorycpu,limits.cpu,requests.cpumemory,limits.memory,requests.memory存儲資源，包括存儲資源的總量以及指定storageclass的總量requests.storage：存儲資源總量，如500Gipersistentvolumeclaims：pvc的個數(shù).storageclass.storage.k8s.io/requests.storage.storageclass.storage.k8s.io/persistentvolumeclaimsrequests.ephemeral-storage和limits.ephemeral-storage（需要v1.8+）對象數(shù)，即可創(chuàng)建的對象的個數(shù)pods,replicationcontrollers,configmaps,secretsresourcequotas,persistentvolumeclaimsservices,services.loadbalancers,services.nodeports——PSP：Pod安全策略；——接口層：kubectl命令行工具、客戶端SDK以及集群聯(lián)邦生態(tài)系統(tǒng)：在接口層之上的龐大容器集群管理調度的生態(tài)系統(tǒng)，可以劃分為兩個范疇Kubernetes外部：日志、監(jiān)控、配置管理、CI、CD、Workflow、FaaS、OTS應用、ChatOps等Kubernetes內部：CRI、CNI、CVI、鏡像倉庫、CloudProvider、集群自身的配置和管理等——OTS：offtheshell？——

核心組件：核心API：

生態(tài)系統(tǒng)：Etcd是CoreOS基于Raft開發(fā)的分布式key-value存儲，可用于服務發(fā)現(xiàn)、共享配置以及一致性保障（如數(shù)據(jù)庫選主、分布式鎖等）。

DaemonSet保證在每個Node上都運行一個容器副本，常用來部署一些集群的日志、監(jiān)控或者其他系統(tǒng)管理應用。典型的應用包括：日志收集，比如fluentd，logstash等系統(tǒng)監(jiān)控，比如PrometheusNodeExporter，collectd，NewRelicagent，Gangliagmond等系統(tǒng)程序，比如kube-proxy,kube-dns,glusterd,ceph等

PersistentVolume(PV)和PersistentVolumeClaim(PVC)提供了方便的持久化卷：PV提供網(wǎng)絡存儲資源，而PVC請求存儲資源。這樣，設置持久化的工作流包括配置底層文件系統(tǒng)或者云數(shù)據(jù)卷、創(chuàng)建持久性數(shù)據(jù)卷、最后創(chuàng)建PVC來將Pod跟數(shù)據(jù)卷關聯(lián)起來。PV和PVC可以將pod和數(shù)據(jù)卷解耦，pod不需要知道確切的文件系統(tǒng)或者支持它的持久化引擎。

Kubernetes在設計之初就充分考慮了針對容器的服務發(fā)現(xiàn)與負載均衡機制，提供了Service資源，并通過kube-proxy配合cloudprovider來適應不同的應用場景。隨著kubernetes用戶的激增，用戶場景的不斷豐富，又產生了一些新的負載均衡機制。目前，kubernetes中的負載均衡大致可以分為以下幾種機制，每種機制都有其特定的應用場景：Service：直接用Service提供cluster內部的負載均衡，并借助cloudprovider提供的LB提供外部訪問IngressController：還是用Service提供cluster內部的負載均衡，但是通過自定義IngressController提供外部訪問ServiceLoadBalancer：把loadbalancer直接跑在容器中，實現(xiàn)BareMetal的ServiceLoadBalancerCustomLoadBalancer：自定義負載均衡，并替代kube-proxy，一般在物理部署Kubernetes時使用，方便接入公司已有的外部服務

網(wǎng)絡插件：https://kubernetes.feisky.xyz/cha-jian-kuo-zhan/network

Cilium是一個基于eBPF和XDP的高性能容器網(wǎng)絡方案，提供了CNI和CNM插件。

Frakti是一個基于KubeletCRI的運行時，它提供了hypervisor級別的隔離性，特別適用于運行不可信應用以及多租戶場景下。Frakti實現(xiàn)了一個混合運行時：特權容器以Dockercontainer的方式運行而普通容器則以hypercontainer的方法運行在VM內

服務治理：

一般準則分離構建和運行環(huán)境使用dumb-int等避免僵尸進程不推薦直接使用Pod，而是推薦使用Deployment/DaemonSet等不推薦在容器中使用后臺進程，而是推薦將進程前臺運行，并使用探針保證服務確實在運行中推薦容器中應用日志打到stdout和stderr，方便日志插件的處理由于容器采用了COW，大量數(shù)據(jù)寫入有可能會有性能問題，推薦將數(shù)據(jù)寫入到Volume中不推薦生產環(huán)境鏡像使用latest標簽，但開發(fā)環(huán)境推薦使用并設置imagePullPolicy為Always推薦使用Readiness探針檢測服務是否真正運行起來了使用activeDeadlineSeconds避免快速失敗的Job無限重啟引入Sidecar處理代理、請求速率控制和連接控制等問題

分離構建和運行環(huán)境注意分離構建和運行環(huán)境，直接通過Dockerfile構建的鏡像不僅體積大，包含了很多運行時不必要的包，并且還容易引入安全隱患，如包含了應用的源代碼?？梢允褂肈ocker多階段構建來簡化這個步驟。

COW：copyonwrite技術

https://juejin.im/post/5bd96bcaf265da396b72f855寫入時復制（英語：Copy-on-write，簡稱COW）是一種計算機程序設計領域的優(yōu)化策略。其核心思想是，如果有多個調用者（callers）同時請求相同資源（如內存或磁盤上的數(shù)據(jù)存儲），他們會共同獲取相同的指針指向相同的資源，直到某個調用者試圖修改資源的內容時，系統(tǒng)才會真正復制一份專用副本（private