|
近幾年來(lái)隨著互聯(lián)網(wǎng)的飛速發(fā)展，新的架構(gòu)實(shí)踐方式不斷涌現(xiàn)，但是有一件事情是永恒不變的，那就是－“架構(gòu)之道”；關(guān)于如何設(shè)計(jì)出靈活、高可用性以及能夠快速適應(yīng)變化的系統(tǒng)架構(gòu)，我們依舊還有很大的發(fā)揮空間。本文會(huì)介紹關(guān)于如何構(gòu)建前沿的、易維護(hù)的、安全的架構(gòu)的幾個(gè)要點(diǎn)，同時(shí)你也可以把它當(dāng)作系統(tǒng)設(shè)計(jì)的準(zhǔn)則或者用它來(lái)驗(yàn)證現(xiàn)有的架構(gòu)是否合理。 就像我們經(jīng)常所說(shuō)的：沒(méi)有最好的架構(gòu)，只有最合適的架構(gòu)。一個(gè)好的架構(gòu)師，可以根據(jù)具體的需求、所擁有的資源等因素綜合考慮而設(shè)計(jì)出最優(yōu)的架構(gòu)方案。特別是現(xiàn)在，業(yè)務(wù)的飛速變化、數(shù)據(jù)無(wú)處不在等這些因素的影響下，技術(shù)和框架也需要在變化的過(guò)程中不斷地打磨和提升以適應(yīng)新的業(yè)務(wù)需要?？赡墚?dāng)時(shí)是最好的架構(gòu)，但是后來(lái)我們還是要跟著業(yè)務(wù)的變化去做改進(jìn)。這并不是一件壞事情，我們只要做好應(yīng)對(duì)變化的準(zhǔn)備即可。 架構(gòu)師這個(gè)詞的意義非常廣泛，有些架構(gòu)師是指在公司負(fù)責(zé)編寫軟件的某些模塊的人。當(dāng)然多數(shù)公司并沒(méi)有這樣的職位，他們會(huì)有一些技術(shù)leader來(lái)負(fù)責(zé)具體的功能。我們這里所要講的架構(gòu)師不會(huì)太過(guò)于關(guān)注代碼的細(xì)節(jié)，而是更關(guān)注系統(tǒng)各個(gè)模塊之間如何協(xié)同、交互等一些更全局的一些事情。他們主要關(guān)注一些可能經(jīng)常會(huì)被人遺忘但是又會(huì)為系統(tǒng)帶來(lái)惡劣影響的部分，職責(zé)是確保所有的功能都能夠以較好的質(zhì)量及時(shí)被交付。這種人對(duì)于軟件產(chǎn)品的成功有著舉足輕重的地位，當(dāng)然他們往往在一個(gè)公司里面可能同時(shí)負(fù)責(zé)好幾個(gè)項(xiàng)目。 想象一下，兩個(gè)不同的架構(gòu)師來(lái)建造一艘太空飛船。第一個(gè)選擇用紙來(lái)糊一個(gè)樣子比較好看的，然后把這艘飛船放到一個(gè)漂亮、大小合適的玻璃櫥窗里面保護(hù)起來(lái)。飛般看起來(lái)可能像下面的這個(gè)樣子： 第二個(gè)架構(gòu)師決定用樂(lè)高模型來(lái)拼一個(gè)太空飛船，它們可以隨意組合并且比較堅(jiān)固，所以并不需要額外的特殊保護(hù)。 兩艘飛船看起來(lái)都是挺不錯(cuò)的，但是第一個(gè)用了較長(zhǎng)的時(shí)間來(lái)完成并且后來(lái)當(dāng)他們需要對(duì)這艘飛船做改進(jìn)的時(shí)候，問(wèn)題就暴露出來(lái)了。 第一位架構(gòu)師幾乎炸了，因?yàn)槊恳淮蔚母膭?dòng)時(shí)候，他們必須要移除那個(gè)保護(hù)罩，并且需要重新再造一艘完整的飛船。雖然他們已經(jīng)有了所有的模型，再加上造飛船對(duì)他來(lái)說(shuō)已經(jīng)很熟悉，但是他們還是花了很長(zhǎng)的時(shí)間去完成每一次改造，另外還需要再做一個(gè)新的保護(hù)罩才能裝的下那艘新的飛船。 但是對(duì)于第二位架構(gòu)師來(lái)說(shuō)，這一切都是不需要的。他只需要對(duì)產(chǎn)生影響的一些組件進(jìn)行改造，制作新的組件，當(dāng)一切準(zhǔn)備就緒再添加到原來(lái)的飛船即可。 再后來(lái)，第二位架構(gòu)師希望能更進(jìn)一步的優(yōu)化他們的制作過(guò)程，因?yàn)樗麄儸F(xiàn)在投入了很多的時(shí)間在上面。在經(jīng)過(guò)一段時(shí)間的研究之后，他們決定嘗試用一種新的材料和方法來(lái)制作這艘飛船。也就是3D打印，他們申請(qǐng)了一臺(tái)3D打印機(jī)，制作了所有的模型，這樣他們就可將一些常規(guī)的任何通過(guò)3D打印機(jī)自動(dòng)完成了。 當(dāng)然，這只是一個(gè)很簡(jiǎn)單的例子。但是我們能從中學(xué)到什么呢？雖然兩位架構(gòu)師在最開(kāi)始的時(shí)候都能成功的完成最初始的功能，但是他們都面臨著變化所帶來(lái)的系統(tǒng)的調(diào)整。在集成階段，復(fù)雜性開(kāi)始顯現(xiàn)出來(lái)，和最開(kāi)始的目標(biāo)無(wú)關(guān)，最終整個(gè)設(shè)計(jì)是否足夠靈活、可調(diào)整、以及模塊化起著至關(guān)重要的作用。 軟件的架構(gòu)至關(guān)重要，僅僅有較好的代碼來(lái)完成功能不足以成為一個(gè)優(yōu)秀的解決方案。因?yàn)樗粌H僅涉及到代碼，還有我們所寫的各個(gè)模塊之間如果交互和集成、數(shù)據(jù)如何存儲(chǔ)、我們?cè)趺礃觼?lái)進(jìn)行開(kāi)發(fā)和測(cè)試、以及在引進(jìn)變動(dòng)的時(shí)候的難易程度等等。 這些事情都是和編寫代碼無(wú)關(guān)，但是需要我們來(lái)花時(shí)間考慮， 并且是整個(gè)系統(tǒng)最后是否成功的決定性因素。 還有一些原則比如：模塊化、輕耦合、無(wú)共享架構(gòu)；減少各個(gè)組件之前的依懶、注意服務(wù)之間依懶所有造成的鏈?zhǔn)绞〖坝绊懙取?/p> DDD給我們提供了在不同的特定領(lǐng)域上下文以及業(yè)務(wù)功能的基礎(chǔ)上拆分組件的指導(dǎo)方法。 把服務(wù)獨(dú)立出來(lái)提供特定的功能，同時(shí)方便在應(yīng)對(duì)變化的時(shí)候能夠不影響其它的服務(wù)。 在大多數(shù)情況下，如果需要同步更新很多個(gè)服務(wù)則說(shuō)明系統(tǒng)的耦合還不夠低。當(dāng)然，再完美的原則也會(huì)有例外的時(shí)候。比如當(dāng)你想把系統(tǒng)部署在一些IoT設(shè)備上的時(shí)候，你可能要一次性部署所有的組件。這是允許的，但是，請(qǐng)盡量考慮服務(wù)之間的耦合及靈活性以應(yīng)對(duì)將系統(tǒng)部署在不同平臺(tái)上的需求。 即便如此，我們也不可能完全避免耦合，它總是會(huì)出現(xiàn)在某些場(chǎng)景下。這就需要我們提取一些抽象層將服務(wù)之間的交互定在契約上來(lái)避免復(fù)雜，提升靈活性。這就需要我們有一種辨別能力，能夠找到那些必須放在一起來(lái)做處理而不能拆解的功能。如果這些功能是值得放在一起的，那我們就可以將它獨(dú)立成一個(gè)微服務(wù)，遵循高聚合的設(shè)計(jì)原因。 我們要記住的是，系統(tǒng)的設(shè)計(jì)要做到比較容易地增加或者修改原來(lái)的組件。無(wú)狀態(tài)的架構(gòu)是系統(tǒng)高擴(kuò)展性的基石。 特別需要注意服務(wù)和組件之間如何交互，了解不同的協(xié)議的優(yōu)缺點(diǎn)，包括速度以及可用性，來(lái)幫助我們來(lái)決定哪一種是最適合我們的。 為配置管理定義策略，因?yàn)橥瑫r(shí)發(fā)生的配置變化對(duì)系統(tǒng)所有造成的影響也是很重要的，所以需要由全局層面的的自動(dòng)化更新方案來(lái)完成。 在如今，對(duì)于一個(gè)數(shù)據(jù)敏感的大型解決方案來(lái)說(shuō)如果沒(méi)有自動(dòng)化的一些基礎(chǔ)設(shè)施和穩(wěn)固的開(kāi)發(fā)、測(cè)試和部署流程，那就和自殺無(wú)異。我們需要花費(fèi)一定時(shí)間來(lái)計(jì)劃和準(zhǔn)備開(kāi)發(fā)、測(cè)試、生產(chǎn)環(huán)境，可能還需要一些額外的環(huán)境以備不時(shí)之需。 測(cè)試流程和策略也是非常重要的。一些最佳實(shí)踐使用Blue-Green開(kāi)發(fā)、金絲雀部署、A/B測(cè)試等。盡量保持測(cè)試環(huán)境與生產(chǎn)環(huán)境是一致的，至少硬件結(jié)構(gòu)上來(lái)說(shuō)應(yīng)該是一樣的。一定要做壓力和負(fù)載測(cè)試，并且盡可能快的在生產(chǎn)上進(jìn)行這樣的測(cè)試，這樣能夠更快速、精確的幫我們找到線上的問(wèn)題。 可調(diào)整的架構(gòu)同時(shí)也意味著服務(wù)要可以被靈活獨(dú)立的部署以及簡(jiǎn)單的基礎(chǔ)運(yùn)維操作。 利用不可變基礎(chǔ)設(shè)施的優(yōu)勢(shì)。 不可變基礎(chǔ)架構(gòu)，就是說(shuō)系統(tǒng)一旦部署，就不再更變升級(jí)。當(dāng)服務(wù)/應(yīng)用需要升級(jí)時(shí)，只要部署一個(gè)新版系統(tǒng)，摧毀舊版就好了。在這個(gè)過(guò)程中，系統(tǒng)對(duì)外服務(wù)是幾乎是持續(xù)的。（譯者注） 保證打包/持續(xù)集成進(jìn)程是基于統(tǒng)一的途徑，并且不會(huì)對(duì)正在運(yùn)行的服務(wù)進(jìn)行任何更改（比如 禁用ssh)，所有的更新都應(yīng)該通過(guò)定義好的自動(dòng)化配置和打包操作將它們應(yīng)用到所有的對(duì)應(yīng)的系統(tǒng)上，來(lái)避免配置遺漏。比如手工某個(gè)環(huán)境上修改配置，可能會(huì)漏掉其它環(huán)境的配置。 開(kāi)發(fā)團(tuán)隊(duì)不應(yīng)該過(guò)度關(guān)注基礎(chǔ)設(shè)施，因?yàn)橛幸惶炜赡芑A(chǔ)設(shè)施也會(huì)發(fā)生改變，所以與業(yè)務(wù)相關(guān)的開(kāi)發(fā)不要和基礎(chǔ)設(shè)施有過(guò)重的綁定。 'in-between the code' 可以統(tǒng)一的概括為一些基礎(chǔ)設(shè)施所提供的功能，比如：服務(wù)發(fā)現(xiàn)、請(qǐng)求路由、網(wǎng)絡(luò)通迅層、代理、負(fù)載均衡等等。很多生產(chǎn)上的錯(cuò)誤并不是因?yàn)榇a的業(yè)務(wù)邏輯錯(cuò)誤或者每個(gè)獨(dú)立組件本身的問(wèn)題，而是由于這些把各個(gè)組件協(xié)調(diào)起來(lái)的一些通用基礎(chǔ)設(shè)施。 隨著系統(tǒng)的變化越來(lái)越快，更要注意我們所更改的一些組件，考慮可用性和擴(kuò)展性。制定最小風(fēng)險(xiǎn)的計(jì)劃來(lái)應(yīng)對(duì)出現(xiàn)的問(wèn)題。 做一個(gè)偏執(zhí)狂。為失敗而設(shè)計(jì)架構(gòu) - 列舉所有可能失敗的地方。和團(tuán)隊(duì)頭腦風(fēng)暴對(duì)所有可能失敗的地方進(jìn)行質(zhì)疑然后提出保護(hù)方案。
使用一些技術(shù)比如：熔斷（circuit breaker）、超時(shí)設(shè)定（timeouts）、握手信號(hào)（handshaking）、艙壁（bulkheads）來(lái)幫助我們保護(hù)這些系統(tǒng)集成之前的問(wèn)題。 熔斷模式（circuit breaker）可以參考電路熔斷，如果一條線路電壓過(guò)高，保險(xiǎn)絲會(huì)熔斷，防止火災(zāi)。放到我們的系統(tǒng)中，如果某個(gè)目標(biāo)服務(wù)調(diào)用慢或者有大量超時(shí)，此時(shí)，熔斷該服務(wù)的調(diào)用，對(duì)于后續(xù)調(diào)用請(qǐng)求，不在繼續(xù)調(diào)用目標(biāo)服務(wù)，直接返回，快速釋放資源。如果目標(biāo)服務(wù)情況好轉(zhuǎn)則恢復(fù)調(diào)用。 艙壁模式（bulkheads）該模式像艙壁一樣對(duì)資源或失敗單元進(jìn)行隔離，如果一個(gè)船艙破了進(jìn)水，只損失一個(gè)船艙。比如采用微服務(wù)是首選，比如Docker。Docker是進(jìn)程隔離的，單個(gè) Docker失效不會(huì)影響其他Docker容器?；蛘甙汛蟮牟⑿刑幚砉ぷ?，由多個(gè)線程池來(lái)負(fù)荷分擔(dān)。 當(dāng)然，如果當(dāng)它開(kāi)始工作的時(shí)候，說(shuō)明我們的系統(tǒng)出現(xiàn)了比較大的問(wèn)題，需要我們?nèi)フ{(diào)查分析。 注意那些不能看到代碼的組件、依懶項(xiàng)以及共享的資源。除了有正確的開(kāi)發(fā)和測(cè)試流程以外，還應(yīng)該盡量使用和真實(shí)生產(chǎn)環(huán)境一樣的數(shù)據(jù)、以及硬件網(wǎng)絡(luò)配置來(lái)進(jìn)行測(cè)試。 跟蹤系統(tǒng)的響應(yīng)來(lái)防止一些比較常見(jiàn)的問(wèn)題比如服務(wù)不可用的情況，留意系統(tǒng)的平均響應(yīng)時(shí)間，當(dāng)它有異常的時(shí)候需要尋找原因以及采取相應(yīng)的行動(dòng)。 搭建日志、監(jiān)控、以及系統(tǒng)操作的自動(dòng)化操作平臺(tái)。由于微服務(wù)相對(duì)來(lái)說(shuō)較獨(dú)立，可以更方便檢測(cè)失敗 所以監(jiān)控起來(lái)會(huì)更容易一些。一些比較不錯(cuò)的方式是在收集和分析日志的時(shí)候使用關(guān)聯(lián)ID、通用日志數(shù)據(jù)格式等。注意日志數(shù)據(jù)可能會(huì)非常龐大，所以要考慮日志的時(shí)間周期，定義對(duì)日志進(jìn)行歸檔。另外還有一些不錯(cuò)的工具可以將數(shù)據(jù)可視化在頁(yè)面中，可以更直觀的看到一些重要的進(jìn)程。 為了保證服務(wù)的更新不會(huì)影響客戶端的使用，對(duì)于服務(wù)的版本控制也是非常重要的。有些情況下同時(shí)運(yùn)行不同版本的服務(wù)也是很常見(jiàn)的情形，我們要做好長(zhǎng)期向后兼容的準(zhǔn)備。 大多數(shù)情況下我們并不是從零開(kāi)始去構(gòu)建，而是在現(xiàn)有的系統(tǒng)上繼續(xù)添磚加瓦，而原有的系統(tǒng)在開(kāi)發(fā)、運(yùn)維、以及架構(gòu)靈活性上都存在一些問(wèn)題。想必很多優(yōu)秀的開(kāi)發(fā)人員在經(jīng)歷這樣的情況的時(shí)候，都會(huì)想去拆解、重構(gòu)整個(gè)系統(tǒng)，但是我們需要謹(jǐn)慎地來(lái)完成這個(gè)事情。當(dāng)系統(tǒng)以錯(cuò)誤的方式成拆分成組件或者服務(wù)單元之后也是一件很危險(xiǎn)的事情 。 大多數(shù)系統(tǒng)在一開(kāi)始的時(shí)候都是一個(gè)單體應(yīng)用，后來(lái)不斷地被拆解成為微服務(wù)。下面有一些基本的理念可以在我們做拆解地時(shí)候當(dāng)作參考：
這個(gè)話題太大，大到我們需要專門寫一篇文章來(lái)細(xì)述。在這里簡(jiǎn)單地概括一下，在本文中我們所提到的架構(gòu)的靈活性以及穩(wěn)健的開(kāi)發(fā)、測(cè)試、運(yùn)維等流程都會(huì)影響企業(yè)的組織結(jié)構(gòu)。合適的組織結(jié)構(gòu)能夠給團(tuán)隊(duì)更大的靈活性并且更有機(jī)會(huì)持續(xù)地創(chuàng)新，在這種組織結(jié)構(gòu)下，團(tuán)隊(duì)可以根據(jù)自己的節(jié)奏來(lái)工作。 組織不應(yīng)該按技術(shù)來(lái)拆分團(tuán)隊(duì)，比如前端團(tuán)隊(duì)、移動(dòng)端團(tuán)隊(duì)、后端團(tuán)隊(duì)或者根據(jù)不同的技術(shù)語(yǔ)言拆分團(tuán)隊(duì)等，而是應(yīng)該按照微服務(wù)來(lái)拆分團(tuán)隊(duì)（也可以理解為按獨(dú)立的業(yè)務(wù)單元來(lái)拆分)。這樣在一個(gè)團(tuán)隊(duì)里面就會(huì)包含各種不同的技術(shù)，可以用不同的語(yǔ)言來(lái)實(shí)現(xiàn)服務(wù)，這也給團(tuán)隊(duì)更多的自由和自主權(quán)。 容器化和集群工具
基礎(chǔ)設(shè)施自動(dòng)化/部署
配置
服務(wù)發(fā)現(xiàn)
路由和負(fù)載均衡
監(jiān)控、跟蹤、日志
數(shù)據(jù)協(xié)議
由于本文涉及到大量的開(kāi)源組件，下面簡(jiǎn)單列舉一些以供參考（部分內(nèi)容來(lái)自于互聯(lián)網(wǎng)）。 Docker Swarm Swarm發(fā)布于2014年12月的DockerCon，用以管理Docker集群，并將其抽象為一個(gè)虛擬整體暴露給用戶。其架構(gòu)以及命令比較簡(jiǎn)單，同時(shí)也為希望管理Docker集群的Docker愛(ài)好者降低了學(xué)習(xí)和使用門檻。 Kubernetes Kubernetes是Google開(kāi)源的容器集群管理系統(tǒng)，其提供應(yīng)用部署、維護(hù)、 擴(kuò)展機(jī)制等功能，利用Kubernetes能方便地管理跨機(jī)器運(yùn)行容器化的應(yīng)用。 Apache Mesos Apache Mesos是由加州大學(xué)伯克利分校的AMPLab首先開(kāi)發(fā)的一款開(kāi)源群集管理軟件，支持Hadoop、ElasticSearch、Spark、Storm 和Kafka等應(yīng)用架構(gòu)。 Mesos Aurora Aurora 也是Apache的開(kāi)源項(xiàng)目之一，是長(zhǎng)期運(yùn)行服務(wù)和計(jì)劃作業(yè)的 Mesos 框架。Aurora 通過(guò)一個(gè)共享機(jī)器池運(yùn)行應(yīng)用和服務(wù)，并且負(fù)責(zé)保持它們的運(yùn)行，知直到永遠(yuǎn)。當(dāng)機(jī)器失效的時(shí)候，Aurora 會(huì)智能的重新規(guī)劃這些作業(yè)到健康的機(jī)器上。 Vagrant Vagrant是一個(gè)基于Ruby的工具，用于創(chuàng)建和部署虛擬化開(kāi)發(fā)環(huán)境。它 使用Oracle的開(kāi)源VirtualBox虛擬化系統(tǒng)，使用 Chef創(chuàng)建自動(dòng)化虛擬環(huán)境。 Packer Packer是一個(gè)開(kāi)源工具，用于從單一配置來(lái)源為多平臺(tái)創(chuàng)建相同的機(jī)器映像。目前支持的平臺(tái)包括Amazon EC2、DigitalOcean、OpenStack、VirtualBox和VMware。 Terraform Terraform 是一個(gè)安全和高效的用來(lái)構(gòu)建、更改和合并基礎(chǔ)架構(gòu)的工具。采用 Go 語(yǔ)言開(kāi)發(fā)。Terraform 可管理已有的流行的服務(wù)，并提供自定義解決方案。 Consul Consul是HashiCorp公司推出的開(kāi)源工具，用于實(shí)現(xiàn)分布式系統(tǒng)的服務(wù)發(fā)現(xiàn)與配置。與其他分布式服務(wù)注冊(cè)與發(fā)現(xiàn)的方案，Consul的方案更'一站式'，內(nèi)置了服務(wù)注冊(cè)與發(fā)現(xiàn)框 架、分布一致性協(xié)議實(shí)現(xiàn)、健康檢查、Key/Value存儲(chǔ)、多數(shù)據(jù)中心方案，不再需要依賴其他工具（比如ZooKeeper等）。使用起來(lái)也較為簡(jiǎn)單。Consul用Golang實(shí)現(xiàn)，因此具有天然可移植性（支持Linux、windows和Mac OS X）；安裝包僅包含一個(gè)可執(zhí)行文件，方便部署，與Docker等輕量級(jí)容器可無(wú)縫配合。 Eureka Eureka 是一個(gè)基于 REST 的服務(wù)，它主要是用于定位服務(wù)，以實(shí)現(xiàn) AWS 云端的負(fù)載均衡和中間層服務(wù)器的故障轉(zhuǎn)移。 Ribbon Ribbon 是 Netflix 發(fā)布的云中間層服務(wù)開(kāi)源項(xiàng)目，其主要功能是提供客戶側(cè)軟件負(fù)載均衡算法。 Zuul Zuul 是提供動(dòng)態(tài)路由，監(jiān)控，彈性，安全等的邊緣服務(wù)。Zuul 相當(dāng)于是設(shè)備和 Netflix 流應(yīng)用的 Web 網(wǎng)站后端所有請(qǐng)求的前門。Zuul 可以適當(dāng)?shù)膶?duì)多個(gè) Amazon Auto Scaling Groups 進(jìn)行路由請(qǐng)求。 Finagle Finagle是Twitter基于Netty開(kāi)發(fā)的支持容錯(cuò)的、協(xié)議無(wú)關(guān)的RPC框架，該框架支撐了Twitter的核心服務(wù)。 Zipkin Zipkin 是 Twitter 的一個(gè)開(kāi)源項(xiàng)目，允許開(kāi)發(fā)者收集 Twitter 各個(gè)服務(wù)上的監(jiān)控?cái)?shù)據(jù)，并提供查詢接口。該系統(tǒng)讓開(kāi)發(fā)者可通過(guò)一個(gè) Web 前端輕松的收集和分析數(shù)據(jù)，例如用戶每次請(qǐng)求服務(wù)的處理時(shí)間等，可方便的監(jiān)測(cè)系統(tǒng)中存在的瓶頸。 Hystrix Hystrix旨在通過(guò)控制那些訪問(wèn)遠(yuǎn)程系統(tǒng)、服務(wù)和第三方庫(kù)的節(jié)點(diǎn)，從而對(duì)延遲和故障提供更強(qiáng)大的容錯(cuò)能力。Hystrix具備擁有回退機(jī)制和斷路器功能的線程和信號(hào)隔離，請(qǐng)求緩存和請(qǐng)求打包（request collapsing，即自動(dòng)批處理，譯者注），以及監(jiān)控和配置等功能。Hystrix源于Netflix API團(tuán)隊(duì)在2011年啟動(dòng)的彈性工程工作，而目前它在Netflix每天處理著數(shù)百億的隔離線程以及數(shù)千億的隔離信號(hào)調(diào)用。Hystrix是基于Apache License 2.0協(xié)議的開(kāi)源的程序庫(kù)，目前托管在GitHub上。 ZooKeeper ZooKeeper是一個(gè)分布式的，開(kāi)放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，是Google的Chubby一個(gè)開(kāi)源的實(shí)現(xiàn)，是Hadoop和Hbase的重要組件。它是一個(gè)為分布式應(yīng)用提供一致性服務(wù)的軟件，提供的功能包括：配置維護(hù)、域名服務(wù)、分布式同步、組服務(wù)等。 etcd etcd是一個(gè)高可用的鍵值存儲(chǔ)系統(tǒng)，主要用于共享配置和服務(wù)發(fā)現(xiàn)。etcd是由CoreOS開(kāi)發(fā)并維護(hù)的，靈感來(lái)自于 ZooKeeper 和 Doozer，它使用Go語(yǔ)言編寫，并通過(guò)Raft一致性算法處理日志復(fù)制以保證強(qiáng)一致性。Raft是一個(gè)來(lái)自Stanford的新的一致性算法，適用于分布式系統(tǒng)的日志復(fù)制，Raft通過(guò)選舉的方式來(lái)實(shí)現(xiàn)一致性，在Raft中，任何一個(gè)節(jié)點(diǎn)都可能成為L(zhǎng)eader。Google的容器集群管理系統(tǒng)Kubernetes、開(kāi)源PaaS平臺(tái)Cloud Foundry和CoreOS的Fleet都廣泛使用了etcd。 Protocol Buffers Protocol Buffers是Google公司開(kāi)發(fā)的一種數(shù)據(jù)描述語(yǔ)言，類似于XML能夠?qū)⒔Y(jié)構(gòu)化數(shù)據(jù)序列化，可用于數(shù)據(jù)存儲(chǔ)、通信協(xié)議等方面。它不依賴于語(yǔ)言和平臺(tái)并且可擴(kuò)展性極強(qiáng)?，F(xiàn)階段官方支持C 、JAVA、Python等三種編程語(yǔ)言，但可以找到大量的幾乎涵蓋所有語(yǔ)言的第三方拓展包。 通過(guò)它，你可以定義你的數(shù)據(jù)的結(jié)構(gòu)，并生成基于各種語(yǔ)言的代碼。這些你定義的數(shù)據(jù)流可以輕松地在傳遞并不破壞你已有的程序。并且你也可以更新這些數(shù)據(jù)而現(xiàn)有的程序也不會(huì)受到任何的影響。 Thrift Thrift是一種可伸縮的跨語(yǔ)言服務(wù)的發(fā)展軟件框架。它結(jié)合了功能強(qiáng)大的軟件堆棧的代碼生成引擎，以建設(shè)服務(wù)，工作效率和無(wú)縫地與C ，C#，Java，Python和PHP和Ruby結(jié)合。thrift是facebook開(kāi)發(fā)的，我們現(xiàn)在把它作為開(kāi)源軟件使用。thrift允許你定義一個(gè)簡(jiǎn)單的定義文件中的數(shù)據(jù)類型和服務(wù)接口。以作為輸入文件，編譯器生成代碼用來(lái)方便地生成RPC客戶端和服務(wù)器通信的無(wú)縫跨編程語(yǔ)言。 本文翻譯自Alena，經(jīng)作者授權(quán)，聊聊架構(gòu)進(jìn)行了全文翻譯。原文地址http://lenadroid./posts/adjustable-flexible-architecture.html 有人認(rèn)為運(yùn)維的過(guò)程像是消防，7*24小時(shí)響應(yīng)異常和危情。事實(shí)上，無(wú)論做什么運(yùn)維，最基本的職責(zé)都是保證業(yè)務(wù)穩(wěn)定運(yùn)行。運(yùn)維以技術(shù)為基礎(chǔ)，通過(guò)技術(shù)保障來(lái)提供更高質(zhì)量的服務(wù)。而服務(wù)監(jiān)控技術(shù)亦是運(yùn)維技術(shù)的重要組成部分，對(duì)服務(wù)運(yùn)行的狀態(tài)進(jìn)行實(shí)時(shí)的監(jiān)控，對(duì)基礎(chǔ)設(shè)施性能進(jìn)行分析，對(duì)App和API進(jìn)行性能監(jiān)控，以及對(duì)用戶體驗(yàn)的監(jiān)控等多種方式來(lái)發(fā)覺(jué)服務(wù)隱患。 |
|
|
