原文地址：http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=411196355&idx=1&sn=be0d574b4a1fd930d897b6b3cf1fbc0a&scene=4#wechat_redirect

近幾年來隨著互聯(lián)網(wǎng)的飛速發(fā)展，新的架構(gòu)實踐方式不斷涌現(xiàn)，但是有一件事情是永恒不變的，那就是－“架構(gòu)之道”；關(guān)于如何設(shè)計出靈活、高可用性以及能夠快速適應(yīng)變化的系統(tǒng)架構(gòu)，我們依舊還有很大的發(fā)揮空間。本文會介紹關(guān)于如何構(gòu)建前沿的、易維護的、安全的架構(gòu)的幾個要點，同時你也可以把它當(dāng)作系統(tǒng)設(shè)計的準(zhǔn)則或者用它來驗證現(xiàn)有的架構(gòu)是否合理。

就像我們經(jīng)常所說的：沒有最好的架構(gòu)，只有最合適的架構(gòu)。一個好的架構(gòu)師，可以根據(jù)具體的需求、所擁有的資源等因素綜合考慮而設(shè)計出最優(yōu)的架構(gòu)方案。特別是現(xiàn)在，業(yè)務(wù)的飛速變化、數(shù)據(jù)無處不在等這些因素的影響下，技術(shù)和框架也需要在變化的過程中不斷地打磨和提升以適應(yīng)新的業(yè)務(wù)需要。可能當(dāng)時是最好的架構(gòu)，但是后來我們還是要跟著業(yè)務(wù)的變化去做改進。這并不是一件壞事情，我們只要做好應(yīng)對變化的準(zhǔn)備即可。

與代碼無關(guān)

架構(gòu)師這個詞的意義非常廣泛，有些架構(gòu)師是指在公司負責(zé)編寫軟件的某些模塊的人。當(dāng)然多數(shù)公司并沒有這樣的職位，他們會有一些技術(shù)leader來負責(zé)具體的功能。我們這里所要講的架構(gòu)師不會太過于關(guān)注代碼的細節(jié)，而是更關(guān)注系統(tǒng)各個模塊之間如何協(xié)同、交互等一些更全局的一些事情。他們主要關(guān)注一些可能經(jīng)常會被人遺忘但是又會為系統(tǒng)帶來惡劣影響的部分，職責(zé)是確保所有的功能都能夠以較好的質(zhì)量及時被交付。這種人對于軟件產(chǎn)品的成功有著舉足輕重的地位，當(dāng)然他們往往在一個公司里面可能同時負責(zé)好幾個項目。

想象一下，兩個不同的架構(gòu)師來建造一艘太空飛船。第一個選擇用紙來糊一個樣子比較好看的，然后把這艘飛船放到一個漂亮、大小合適的玻璃櫥窗里面保護起來。飛般看起來可能像下面的這個樣子：

第二個架構(gòu)師決定用樂高模型來拼一個太空飛船，它們可以隨意組合并且比較堅固，所以并不需要額外的特殊保護。

兩艘飛船看起來都是挺不錯的，但是第一個用了較長的時間來完成并且后來當(dāng)他們需要對這艘飛船做改進的時候，問題就暴露出來了。

第一位架構(gòu)師幾乎炸了，因為每一次的改動時候，他們必須要移除那個保護罩，并且需要重新再造一艘完整的飛船。雖然他們已經(jīng)有了所有的模型，再加上造飛船對他來說已經(jīng)很熟悉，但是他們還是花了很長的時間去完成每一次改造，另外還需要再做一個新的保護罩才能裝的下那艘新的飛船。

但是對于第二位架構(gòu)師來說，這一切都是不需要的。他只需要對產(chǎn)生影響的一些組件進行改造，制作新的組件，當(dāng)一切準(zhǔn)備就緒再添加到原來的飛船即可。

再后來，第二位架構(gòu)師希望能更進一步的優(yōu)化他們的制作過程，因為他們現(xiàn)在投入了很多的時間在上面。在經(jīng)過一段時間的研究之后，他們決定嘗試用一種新的材料和方法來制作這艘飛船。也就是3D打印，他們申請了一臺3D打印機，制作了所有的模型，這樣他們就可將一些常規(guī)的任何通過3D打印機自動完成了。

當(dāng)然，這只是一個很簡單的例子。但是我們能從中學(xué)到什么呢？雖然兩位架構(gòu)師在最開始的時候都能成功的完成最初始的功能，但是他們都面臨著變化所帶來的系統(tǒng)的調(diào)整。在集成階段，復(fù)雜性開始顯現(xiàn)出來，和最開始的目標(biāo)無關(guān)，最終整個設(shè)計是否足夠靈活、可調(diào)整、以及模塊化起著至關(guān)重要的作用。

軟件的架構(gòu)至關(guān)重要，僅僅有較好的代碼來完成功能不足以成為一個優(yōu)秀的解決方案。因為它不僅僅涉及到代碼，還有我們所寫的各個模塊之間如果交互和集成、數(shù)據(jù)如何存儲、我們怎么樣來進行開發(fā)和測試、以及在引進變動的時候的難易程度等等。

這些事情都是和編寫代碼無關(guān)，但是需要我們來花時間考慮， 并且是整個系統(tǒng)最后是否成功的決定性因素。

需要考慮的細節(jié)

還有一些原則比如：模塊化、輕耦合、無共享架構(gòu)；減少各個組件之前的依懶、注意服務(wù)之間依懶所有造成的鏈?zhǔn)绞〖坝绊懙取?/p>

DDD給我們提供了在不同的特定領(lǐng)域上下文以及業(yè)務(wù)功能的基礎(chǔ)上拆分組件的指導(dǎo)方法。

把服務(wù)獨立出來提供特定的功能，同時方便在應(yīng)對變化的時候能夠不影響其它的服務(wù)。

在大多數(shù)情況下，如果需要同步更新很多個服務(wù)則說明系統(tǒng)的耦合還不夠低。當(dāng)然，再完美的原則也會有例外的時候。比如當(dāng)你想把系統(tǒng)部署在一些IoT設(shè)備上的時候，你可能要一次性部署所有的組件。這是允許的，但是，請盡量考慮服務(wù)之間的耦合及靈活性以應(yīng)對將系統(tǒng)部署在不同平臺上的需求。

即便如此，我們也不可能完全避免耦合，它總是會出現(xiàn)在某些場景下。這就需要我們提取一些抽象層將服務(wù)之間的交互定在契約上來避免復(fù)雜，提升靈活性。這就需要我們有一種辨別能力，能夠找到那些必須放在一起來做處理而不能拆解的功能。如果這些功能是值得放在一起的，那我們就可以將它獨立成一個微服務(wù)，遵循高聚合的設(shè)計原因。

我們要記住的是，系統(tǒng)的設(shè)計要做到比較容易地增加或者修改原來的組件。無狀態(tài)的架構(gòu)是系統(tǒng)高擴展性的基石。

特別需要注意服務(wù)和組件之間如何交互，了解不同的協(xié)議的優(yōu)缺點，包括速度以及可用性，來幫助我們來決定哪一種是最適合我們的。

基礎(chǔ)設(shè)施、配置、測試、開發(fā)、運維

為配置管理定義策略，因為同時發(fā)生的配置變化對系統(tǒng)所有造成的影響也是很重要的，所以需要由全局層面的的自動化更新方案來完成。

在如今，對于一個數(shù)據(jù)敏感的大型解決方案來說如果沒有自動化的一些基礎(chǔ)設(shè)施和穩(wěn)固的開發(fā)、測試和部署流程，那就和自殺無異。我們需要花費一定時間來計劃和準(zhǔn)備開發(fā)、測試、生產(chǎn)環(huán)境，可能還需要一些額外的環(huán)境以備不時之需。

測試流程和策略也是非常重要的。一些最佳實踐使用Blue-Green開發(fā)、金絲雀部署、A/B測試等。盡量保持測試環(huán)境與生產(chǎn)環(huán)境是一致的，至少硬件結(jié)構(gòu)上來說應(yīng)該是一樣的。一定要做壓力和負載測試，并且盡可能快的在生產(chǎn)上進行這樣的測試，這樣能夠更快速、精確的幫我們找到線上的問題。

可調(diào)整的架構(gòu)同時也意味著服務(wù)要可以被靈活獨立的部署以及簡單的基礎(chǔ)運維操作。

利用不可變基礎(chǔ)設(shè)施的優(yōu)勢。

不可變基礎(chǔ)架構(gòu)，就是說系統(tǒng)一旦部署，就不再更變升級。當(dāng)服務(wù)/應(yīng)用需要升級時，只要部署一個新版系統(tǒng)，摧毀舊版就好了。在這個過程中，系統(tǒng)對外服務(wù)是幾乎是持續(xù)的。（譯者注）

保證打包/持續(xù)集成進程是基于統(tǒng)一的途徑，并且不會對正在運行的服務(wù)進行任何更改（比如 禁用ssh)，所有的更新都應(yīng)該通過定義好的自動化配置和打包操作將它們應(yīng)用到所有的對應(yīng)的系統(tǒng)上，來避免配置遺漏。比如手工某個環(huán)境上修改配置，可能會漏掉其它環(huán)境的配置。

開發(fā)團隊不應(yīng)該過度關(guān)注基礎(chǔ)設(shè)施，因為有一天可能基礎(chǔ)設(shè)施也會發(fā)生改變，所以與業(yè)務(wù)相關(guān)的開發(fā)不要和基礎(chǔ)設(shè)施有過重的綁定。

代碼之間的東西（in-between the code）

"in-between the code" 可以統(tǒng)一的概括為一些基礎(chǔ)設(shè)施所提供的功能，比如：服務(wù)發(fā)現(xiàn)、請求路由、網(wǎng)絡(luò)通迅層、代理、負載均衡等等。很多生產(chǎn)上的錯誤并不是因為代碼的業(yè)務(wù)邏輯錯誤或者每個獨立組件本身的問題，而是由于這些把各個組件協(xié)調(diào)起來的一些通用基礎(chǔ)設(shè)施。

隨著系統(tǒng)的變化越來越快，更要注意我們所更改的一些組件，考慮可用性和擴展性。制定最小風(fēng)險的計劃來應(yīng)對出現(xiàn)的問題。

無處不在的坑

做一個偏執(zhí)狂。為失敗而設(shè)計架構(gòu) - 列舉所有可能失敗的地方。和團隊頭腦風(fēng)暴對所有可能失敗的地方進行質(zhì)疑然后提出保護方案。

• 如果連接建立失敗怎么辦？

• 如果花費的時間超出預(yù)計怎么辦？

• 如果請求返回不清楚的數(shù)據(jù)或者不正確的答案怎么辦？

• 如果請求返回的數(shù)據(jù)不是約定好的怎么辦？

• 如果出現(xiàn)很高的并發(fā)能應(yīng)對嗎？

• 如果服務(wù)掛、機組、整個數(shù)據(jù)中心掛掉了怎么辦？

• 如果數(shù)據(jù)庫損壞了怎么辦？

• 如果部署的時候失敗了怎么辦？

• 如果在部署成功之后生產(chǎn)環(huán)境上某些功能失敗了怎么辦？

• 集成性這方面的錯誤可以有千萬種可能，那么我們應(yīng)該如何來避免？

使用一些技術(shù)比如：熔斷（circuit breaker）、超時設(shè)定（timeouts）、握手信號（handshaking）、艙壁（bulkheads）來幫助我們保護這些系統(tǒng)集成之前的問題。

熔斷模式（circuit breaker）可以參考電路熔斷，如果一條線路電壓過高，保險絲會熔斷，防止火災(zāi)。放到我們的系統(tǒng)中，如果某個目標(biāo)服務(wù)調(diào)用慢或者有大量超時，此時，熔斷該服務(wù)的調(diào)用，對于后續(xù)調(diào)用請求，不在繼續(xù)調(diào)用目標(biāo)服務(wù)，直接返回，快速釋放資源。如果目標(biāo)服務(wù)情況好轉(zhuǎn)則恢復(fù)調(diào)用。

艙壁模式（bulkheads）該模式像艙壁一樣對資源或失敗單元進行隔離，如果一個船艙破了進水，只損失一個船艙。比如采用微服務(wù)是首選，比如Docker。Docker是進程隔離的，單個 Docker失效不會影響其他Docker容器。或者把大的并行處理工作，由多個線程池來負荷分擔(dān)。

當(dāng)然，如果當(dāng)它開始工作的時候，說明我們的系統(tǒng)出現(xiàn)了比較大的問題，需要我們?nèi)フ{(diào)查分析。

注意那些不能看到代碼的組件、依懶項以及共享的資源。除了有正確的開發(fā)和測試流程以外，還應(yīng)該盡量使用和真實生產(chǎn)環(huán)境一樣的數(shù)據(jù)、以及硬件網(wǎng)絡(luò)配置來進行測試。

跟蹤系統(tǒng)的響應(yīng)來防止一些比較常見的問題比如服務(wù)不可用的情況，留意系統(tǒng)的平均響應(yīng)時間，當(dāng)它有異常的時候需要尋找原因以及采取相應(yīng)的行動。

搭建日志、監(jiān)控、以及系統(tǒng)操作的自動化操作平臺。由于微服務(wù)相對來說較獨立，可以更方便檢測失敗 所以監(jiān)控起來會更容易一些。一些比較不錯的方式是在收集和分析日志的時候使用關(guān)聯(lián)ID、通用日志數(shù)據(jù)格式等。注意日志數(shù)據(jù)可能會非常龐大，所以要考慮日志的時間周期，定義對日志進行歸檔。另外還有一些不錯的工具可以將數(shù)據(jù)可視化在頁面中，可以更直觀的看到一些重要的進程。

為了保證服務(wù)的更新不會影響客戶端的使用，對于服務(wù)的版本控制也是非常重要的。有些情況下同時運行不同版本的服務(wù)也是很常見的情形，我們要做好長期向后兼容的準(zhǔn)備。

務(wù)必要記住的事情

大多數(shù)情況下我們并不是從零開始去構(gòu)建，而是在現(xiàn)有的系統(tǒng)上繼續(xù)添磚加瓦，而原有的系統(tǒng)在開發(fā)、運維、以及架構(gòu)靈活性上都存在一些問題。想必很多優(yōu)秀的開發(fā)人員在經(jīng)歷這樣的情況的時候，都會想去拆解、重構(gòu)整個系統(tǒng)，但是我們需要謹慎地來完成這個事情。當(dāng)系統(tǒng)以錯誤的方式成拆分成組件或者服務(wù)單元之后也是一件很危險的事情 。

大多數(shù)系統(tǒng)在一開始的時候都是一個單體應(yīng)用，后來不斷地被拆解成為微服務(wù)。下面有一些基本的理念可以在我們做拆解地時候當(dāng)作參考：

• 在開始拆分前了解具體的業(yè)務(wù)需求和業(yè)務(wù)領(lǐng)域

• 注意一些和其它業(yè)務(wù)共享的功能和數(shù)據(jù)，它們需要被正確地模塊化

• 這種遷移和升級適合一步一步、一點一點地來完成，僅僅做當(dāng)前最合適的事情

• 在開始之前很好地理解業(yè)務(wù)領(lǐng)域的范圍及邊界，因為對邊界的調(diào)整將是非常昂貴的

• 對于改造有清晰的結(jié)構(gòu)此次會涉及到哪些團隊的調(diào)整

人、團隊、和組織的影響

這個話題太大，大到我們需要專門寫一篇文章來細述。在這里簡單地概括一下，在本文中我們所提到的架構(gòu)的靈活性以及穩(wěn)健的開發(fā)、測試、運維等流程都會影響企業(yè)的組織結(jié)構(gòu)。合適的組織結(jié)構(gòu)能夠給團隊更大的靈活性并且更有機會持續(xù)地創(chuàng)新，在這種組織結(jié)構(gòu)下，團隊可以根據(jù)自己的節(jié)奏來工作。

組織不應(yīng)該按技術(shù)來拆分團隊，比如前端團隊、移動端團隊、后端團隊或者根據(jù)不同的技術(shù)語言拆分團隊等，而是應(yīng)該按照微服務(wù)來拆分團隊（也可以理解為按獨立的業(yè)務(wù)單元來拆分)。這樣在一個團隊里面就會包含各種不同的技術(shù)，可以用不同的語言來實現(xiàn)服務(wù)，這也給團隊更多的自由和自主權(quán)。

?

如何實踐？

容器化和集群工具

• Docker

• Docker Swarm

• Kubernetes

• Mesos

• Serf

• Nomad

基礎(chǔ)設(shè)施自動化/部署

• Jenkins

• Terraform

• Vagrant

• Packer

• Otto

• Chef、Puppet、 Ansible

配置

• Edda

• Archaius

• Decider

• ZooKeeper

服務(wù)發(fā)現(xiàn)

• Eureka

• Prana

• Finagle

• ZooKeeper

• Consul

路由和負載均衡

• Denominator

• Zuul

• Netty

• Ribbon

• HAProxy

• NGINX

監(jiān)控、跟蹤、日志

• Hystrix

• Consul health checks

• Zipkin

• Pytheus

• SALP

• Elasticsearch logstash

數(shù)據(jù)協(xié)議

• Protocol Buffers

• Thrift

• JSON/XML/Other text

?

一些關(guān)于以上工具的介紹

?

由于本文涉及到大量的開源組件，下面簡單列舉一些以供參考（部分內(nèi)容來自于互聯(lián)網(wǎng)）。

Docker Swarm

Swarm發(fā)布于2014年12月的DockerCon，用以管理Docker集群，并將其抽象為一個虛擬整體暴露給用戶。其架構(gòu)以及命令比較簡單，同時也為希望管理Docker集群的Docker愛好者降低了學(xué)習(xí)和使用門檻。

Kubernetes

Kubernetes是Google開源的容器集群管理系統(tǒng)，其提供應(yīng)用部署、維護、 擴展機制等功能，利用Kubernetes能方便地管理跨機器運行容器化的應(yīng)用。

Apache Mesos

Apache Mesos是由加州大學(xué)伯克利分校的AMPLab首先開發(fā)的一款開源群集管理軟件，支持Hadoop、ElasticSearch、Spark、Storm 和Kafka等應(yīng)用架構(gòu)。

Mesos Aurora

Aurora 也是Apache的開源項目之一，是長期運行服務(wù)和計劃作業(yè)的 Mesos 框架。Aurora 通過一個共享機器池運行應(yīng)用和服務(wù)，并且負責(zé)保持它們的運行，知直到永遠。當(dāng)機器失效的時候，Aurora 會智能的重新規(guī)劃這些作業(yè)到健康的機器上。

Vagrant

Vagrant是一個基于Ruby的工具，用于創(chuàng)建和部署虛擬化開發(fā)環(huán)境。它 使用Oracle的開源VirtualBox虛擬化系統(tǒng)，使用 Chef創(chuàng)建自動化虛擬環(huán)境。

Packer

Packer是一個開源工具，用于從單一配置來源為多平臺創(chuàng)建相同的機器映像。目前支持的平臺包括Amazon EC2、DigitalOcean、OpenStack、VirtualBox和VMware。

Terraform

Terraform 是一個安全和高效的用來構(gòu)建、更改和合并基礎(chǔ)架構(gòu)的工具。采用 Go 語言開發(fā)。Terraform 可管理已有的流行的服務(wù)，并提供自定義解決方案。

Consul

Consul是HashiCorp公司推出的開源工具，用于實現(xiàn)分布式系統(tǒng)的服務(wù)發(fā)現(xiàn)與配置。與其他分布式服務(wù)注冊與發(fā)現(xiàn)的方案，Consul的方案更"一站式"，內(nèi)置了服務(wù)注冊與發(fā)現(xiàn)框 架、分布一致性協(xié)議實現(xiàn)、健康檢查、Key/Value存儲、多數(shù)據(jù)中心方案，不再需要依賴其他工具（比如ZooKeeper等）。使用起來也較為簡單。Consul用Golang實現(xiàn)，因此具有天然可移植性（支持Linux、windows和Mac OS X）；安裝包僅包含一個可執(zhí)行文件，方便部署，與Docker等輕量級容器可無縫配合。

Eureka

Eureka 是一個基于 REST 的服務(wù)，它主要是用于定位服務(wù)，以實現(xiàn) AWS 云端的負載均衡和中間層服務(wù)器的故障轉(zhuǎn)移。

Ribbon

Ribbon 是 Netflix 發(fā)布的云中間層服務(wù)開源項目，其主要功能是提供客戶側(cè)軟件負載均衡算法。

Zuul

Zuul 是提供動態(tài)路由，監(jiān)控，彈性，安全等的邊緣服務(wù)。Zuul 相當(dāng)于是設(shè)備和 Netflix 流應(yīng)用的 Web 網(wǎng)站后端所有請求的前門。Zuul 可以適當(dāng)?shù)膶Χ鄠€ Amazon Auto Scaling Groups 進行路由請求。

Finagle

Finagle是Twitter基于Netty開發(fā)的支持容錯的、協(xié)議無關(guān)的RPC框架，該框架支撐了Twitter的核心服務(wù)。

Zipkin

Zipkin 是 Twitter 的一個開源項目，允許開發(fā)者收集 Twitter 各個服務(wù)上的監(jiān)控數(shù)據(jù)，并提供查詢接口。該系統(tǒng)讓開發(fā)者可通過一個 Web 前端輕松的收集和分析數(shù)據(jù)，例如用戶每次請求服務(wù)的處理時間等，可方便的監(jiān)測系統(tǒng)中存在的瓶頸。

Hystrix

Hystrix旨在通過控制那些訪問遠程系統(tǒng)、服務(wù)和第三方庫的節(jié)點，從而對延遲和故障提供更強大的容錯能力。Hystrix具備擁有回退機制和斷路器功能的線程和信號隔離，請求緩存和請求打包（request collapsing，即自動批處理，譯者注），以及監(jiān)控和配置等功能。Hystrix源于Netflix API團隊在2011年啟動的彈性工程工作，而目前它在Netflix每天處理著數(shù)百億的隔離線程以及數(shù)千億的隔離信號調(diào)用。Hystrix是基于Apache License 2.0協(xié)議的開源的程序庫，目前托管在GitHub上。

ZooKeeper

ZooKeeper是一個分布式的，開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，是Google的Chubby一個開源的實現(xiàn)，是Hadoop和Hbase的重要組件。它是一個為分布式應(yīng)用提供一致性服務(wù)的軟件，提供的功能包括：配置維護、域名服務(wù)、分布式同步、組服務(wù)等。

etcd

etcd是一個高可用的鍵值存儲系統(tǒng)，主要用于共享配置和服務(wù)發(fā)現(xiàn)。etcd是由CoreOS開發(fā)并維護的，靈感來自于 ZooKeeper 和 Doozer，它使用Go語言編寫，并通過Raft一致性算法處理日志復(fù)制以保證強一致性。Raft是一個來自Stanford的新的一致性算法，適用于分布式系統(tǒng)的日志復(fù)制，Raft通過選舉的方式來實現(xiàn)一致性，在Raft中，任何一個節(jié)點都可能成為Leader。Google的容器集群管理系統(tǒng)Kubernetes、開源PaaS平臺Cloud Foundry和CoreOS的Fleet都廣泛使用了etcd。

Protocol Buffers

Protocol Buffers是Google公司開發(fā)的一種數(shù)據(jù)描述語言，類似于XML能夠?qū)⒔Y(jié)構(gòu)化數(shù)據(jù)序列化，可用于數(shù)據(jù)存儲、通信協(xié)議等方面。它不依賴于語言和平臺并且可擴展性極強。現(xiàn)階段官方支持C++、JAVA、Python等三種編程語言，但可以找到大量的幾乎涵蓋所有語言的第三方拓展包。

通過它，你可以定義你的數(shù)據(jù)的結(jié)構(gòu)，并生成基于各種語言的代碼。這些你定義的數(shù)據(jù)流可以輕松地在傳遞并不破壞你已有的程序。并且你也可以更新這些數(shù)據(jù)而現(xiàn)有的程序也不會受到任何的影響。

Thrift

Thrift是一種可伸縮的跨語言服務(wù)的發(fā)展軟件框架。它結(jié)合了功能強大的軟件堆棧的代碼生成引擎，以建設(shè)服務(wù)，工作效率和無縫地與C + +，C#，Java，Python和PHP和Ruby結(jié)合。thrift是facebook開發(fā)的，我們現(xiàn)在把它作為開源軟件使用。thrift允許你定義一個簡單的定義文件中的數(shù)據(jù)類型和服務(wù)接口。以作為輸入文件，編譯器生成代碼用來方便地生成RPC客戶端和服務(wù)器通信的無縫跨編程語言。

本文翻譯自Alena，經(jīng)作者授權(quán)，聊聊架構(gòu)進行了全文翻譯。原文地址http://lenadroid.github.io/posts/adjustable-flexible-architecture.html

?

號外號外

有人認為運維的過程像是消防，7*24小時響應(yīng)異常和危情。事實上，無論做什么運維，最基本的職責(zé)都是保證業(yè)務(wù)穩(wěn)定運行。運維以技術(shù)為基礎(chǔ)，通過技術(shù)保障來提供更高質(zhì)量的服務(wù)。而服務(wù)監(jiān)控技術(shù)亦是運維技術(shù)的重要組成部分，對服務(wù)運行的狀態(tài)進行實時的監(jiān)控，對基礎(chǔ)設(shè)施性能進行分析，對App和API進行性能監(jiān)控，以及對用戶體驗的監(jiān)控等多種方式來發(fā)覺服務(wù)隱患。

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/5415740.html

總結(jié)

以上是生活随笔為你收集整理的关于架构的优化和设计，架构师必须悟透的事情的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。