作為一個(gè)架構(gòu)師，在做應(yīng)用系統(tǒng)架構(gòu)時(shí)，最好逐步沉淀自己的一套指導(dǎo)思想，指導(dǎo)思想用于在做架構(gòu)設(shè)計(jì)過(guò)程中遇到困惑或遇事不決時(shí)的一個(gè)指引。我個(gè)人總結(jié)下來(lái)的經(jīng)驗(yàn)有以下三點(diǎn)架構(gòu)是一個(gè)復(fù)雜的工作，既要考慮當(dāng)下的需求，還要關(guān)注未來(lái)可能的變化；既要考慮的足夠全面，還要簡(jiǎn)單容易實(shí)現(xiàn)；既要衡量實(shí)現(xiàn)成本，還要關(guān)注落地的效率。這些無(wú)不意味著在做架構(gòu)時(shí)需做好平衡，學(xué)會(huì)取舍。一個(gè)好的架構(gòu)，一定是經(jīng)過(guò)長(zhǎng)期迭代演進(jìn)而來(lái)的。在做架構(gòu)設(shè)計(jì)時(shí)，受限于當(dāng)前已經(jīng)明確的需求，往往無(wú)法對(duì)未來(lái)考慮的那么全面。即使在做架構(gòu)設(shè)計(jì)時(shí)已經(jīng)考慮到了方方面面，系統(tǒng)上線后也會(huì)遇到一些新的未知問(wèn)題，并且隨著需求的不斷迭代，又會(huì)引入新的變化和挑戰(zhàn)，因此持續(xù)的對(duì)架構(gòu)做優(yōu)化和迭代演進(jìn)，是必須要重視的。沒(méi)有毫無(wú)瑕疵完美的架構(gòu)，也沒(méi)有一成不變適合所有業(yè)務(wù)的架構(gòu)，只有適合當(dāng)前業(yè)務(wù)和產(chǎn)品需求的架構(gòu)。我們可以借鑒、吸收別人的經(jīng)驗(yàn)和實(shí)踐總結(jié)，但最合適的架構(gòu)一定是結(jié)合業(yè)務(wù)的實(shí)際需求設(shè)計(jì)和演變出來(lái)的。脫離業(yè)務(wù)需求設(shè)計(jì)的架構(gòu)一定會(huì)在開(kāi)發(fā)中遇到新的問(wèn)題。架構(gòu)設(shè)計(jì)目標(biāo)在做應(yīng)用系統(tǒng)架構(gòu)設(shè)計(jì)時(shí)，應(yīng)遵循一些普適的架構(gòu)設(shè)計(jì)目標(biāo)。這些目標(biāo)包括- 可實(shí)現(xiàn)的：架構(gòu)被設(shè)計(jì)出來(lái)，一定是需要能夠被實(shí)現(xiàn)和落地的，如果設(shè)計(jì)架構(gòu)所采用的技術(shù)還沒(méi)成熟或不具備生產(chǎn)環(huán)境可用性，這種架構(gòu)只能停留在理論階段，不具備落地的可行性，這樣的架構(gòu)也就沒(méi)有特別大的價(jià)值和意義。
- 可擴(kuò)展的：雖然無(wú)法預(yù)知需求未來(lái)的變化，但有些場(chǎng)景下，我們?cè)O(shè)計(jì)的架構(gòu)也應(yīng)該具備當(dāng)用戶量、帶寬、數(shù)據(jù)量等增長(zhǎng)時(shí)，具備較好的擴(kuò)展性；除此之外，在做需求分析時(shí)，把系統(tǒng)、領(lǐng)域服務(wù)甚至模塊做好規(guī)劃和設(shè)計(jì)，能夠合理的應(yīng)對(duì)未來(lái)需求膨脹可能帶來(lái)的問(wèn)題，也是架構(gòu)可擴(kuò)展性的一種體現(xiàn)。
- 高可用的：系統(tǒng)架構(gòu)需要考慮各種異常情況下系統(tǒng)可用性，如流量的突然爆發(fā)的消峰限流，某個(gè)服務(wù)或接口故障后的降級(jí)等，通過(guò)在架構(gòu)中設(shè)計(jì)的各種措施保障整個(gè)應(yīng)用系統(tǒng)是高可用的。
- 可衡量的：應(yīng)用系統(tǒng)架構(gòu)設(shè)計(jì)最終都需要落地到代碼層面實(shí)現(xiàn)，提供出可線上發(fā)布的系統(tǒng)和服務(wù)。我們?cè)谧鱿到y(tǒng)架構(gòu)設(shè)計(jì)時(shí)，需要根據(jù)業(yè)務(wù)數(shù)據(jù)的預(yù)估，設(shè)計(jì)出滿足一定量級(jí)的系統(tǒng)數(shù)據(jù)指標(biāo)，將架構(gòu)設(shè)計(jì)的結(jié)果量化。在遇到系統(tǒng)負(fù)載過(guò)高需要擴(kuò)容時(shí)，就可以參考定量的數(shù)據(jù)指標(biāo)預(yù)估出所需的服務(wù)器和資源等。
接下來(lái)從業(yè)務(wù)需求分析開(kāi)始，到最終系統(tǒng)上線運(yùn)營(yíng)，按照不同階段需要關(guān)注的知識(shí)和內(nèi)容，來(lái)說(shuō)明整個(gè)應(yīng)用系統(tǒng)架構(gòu)設(shè)計(jì)過(guò)程需要考慮的問(wèn)題。正如前文所述，系統(tǒng)架構(gòu)應(yīng)該是聚焦業(yè)務(wù)需求的，業(yè)務(wù)需求分析，是做系統(tǒng)架構(gòu)設(shè)計(jì)的必要前置。這里簡(jiǎn)述下我在需求分析階段工作的大致思路。正常情況下，進(jìn)入到架構(gòu)師層面的需求，都經(jīng)過(guò)了業(yè)務(wù)人員和產(chǎn)品人員至少一輪的討論溝通，或已經(jīng)有基本的業(yè)務(wù)和產(chǎn)品需求雛形，或已經(jīng)產(chǎn)出業(yè)務(wù)的MRD(業(yè)務(wù)需求說(shuō)明書(shū))或產(chǎn)品的PRD(產(chǎn)品需求說(shuō)明書(shū))。這時(shí)架構(gòu)師進(jìn)入后需要再和業(yè)務(wù)及產(chǎn)品同學(xué)進(jìn)行充分的討論溝通，明確和產(chǎn)出以下幾點(diǎn)信息：- 確定清楚業(yè)務(wù)目標(biāo)，搞清楚業(yè)務(wù)需要解決的核心問(wèn)題是什么，通過(guò)產(chǎn)品和系統(tǒng)期望帶來(lái)的效果是怎樣的。
- 進(jìn)行業(yè)務(wù)流程梳理和業(yè)務(wù)建模。業(yè)務(wù)建模的核心在于梳理清楚用戶角色、業(yè)務(wù)場(chǎng)景、流程和相關(guān)規(guī)則策略。弄清楚不同用戶角色在哪些場(chǎng)景下可以進(jìn)行什么樣的操作，由此對(duì)業(yè)務(wù)有更清晰的全局認(rèn)識(shí)。
- 根據(jù)業(yè)務(wù)模型、業(yè)務(wù)產(chǎn)出的MRD或產(chǎn)品產(chǎn)出的PRD，整理出大概的子系統(tǒng)和功能列表。功能列表先從第一層級(jí)梳理，再層層細(xì)化，一般以不超過(guò)四層為宜。如第一層級(jí)分為用戶管理、訂單管理、售后退換貨管理等。第二層級(jí)中用戶管理再細(xì)分為注冊(cè)登陸，基礎(chǔ)資料維護(hù)、禁用啟用等，依次類推。
- 根據(jù)業(yè)務(wù)模型和功能列表，預(yù)估和完善非功能性需求，如對(duì)總用戶量、同時(shí)在線用戶量、系統(tǒng)訪問(wèn)量等非功能需求，系統(tǒng)性能、響應(yīng)時(shí)間、qps等系統(tǒng)性能要求，系統(tǒng)工期、人員投入、項(xiàng)目組織結(jié)構(gòu)、其它成本等項(xiàng)目約束條件等。
在需求分析階段，我會(huì)最終產(chǎn)出一份基于業(yè)務(wù)模型拆解出的功能需求列表和非功能需求列表。這將作為后續(xù)應(yīng)用系統(tǒng)架構(gòu)的核心參考和依據(jù)。在需求分析階段完成后，就進(jìn)入到系統(tǒng)架構(gòu)設(shè)計(jì)階段。在系統(tǒng)架構(gòu)設(shè)計(jì)階段，我一般會(huì)首先做數(shù)據(jù)建模。根據(jù)業(yè)務(wù)模型和功能列表，已經(jīng)可以分清楚大概的系統(tǒng)、模塊和功能，由此數(shù)據(jù)庫(kù)的概念模型基本能夠確定下來(lái)。通過(guò)數(shù)據(jù)庫(kù)的概念模型設(shè)計(jì)，結(jié)合需求分析階段產(chǎn)出的功能需求列表，整個(gè)系統(tǒng)的詳細(xì)需求基本可以被印在大腦中了。同時(shí)經(jīng)過(guò)概念模型的設(shè)計(jì)，不同數(shù)據(jù)實(shí)體之間的關(guān)系已經(jīng)相對(duì)清晰，服務(wù)或領(lǐng)域的劃分也具備初步的雛形了。完成數(shù)據(jù)庫(kù)的概念模型后，開(kāi)始進(jìn)行詳細(xì)的系統(tǒng)架構(gòu)設(shè)計(jì)和技術(shù)選型階段。在系統(tǒng)架構(gòu)設(shè)計(jì)階段，我會(huì)按照分層架構(gòu)設(shè)計(jì)的思想，逐步做細(xì)化展開(kāi)。在目前的主流技術(shù)方案中，前后端分離基本上是默認(rèn)的標(biāo)準(zhǔn)，核心原因一方面是前后端技術(shù)演進(jìn)快速發(fā)展，技術(shù)專業(yè)人員分工更明確；另一方面當(dāng)前的產(chǎn)品開(kāi)始移動(dòng)化，前后端一體的架構(gòu)無(wú)法支撐當(dāng)前移動(dòng)端特別是App類應(yīng)用的開(kāi)發(fā)，前后端分離也成為不得不為之的舉措。按照分層架構(gòu)設(shè)計(jì)的思想，將整個(gè)架構(gòu)分為前端接入層、服務(wù)層、數(shù)據(jù)訪問(wèn)層、數(shù)據(jù)存儲(chǔ)層。在部分高并發(fā)的系統(tǒng)中，還會(huì)有緩存相關(guān)技術(shù)貫穿在整個(gè)架構(gòu)層級(jí)之間。首先，在前端接入層，主要解決用戶流量從終端發(fā)起請(qǐng)求到被應(yīng)用服務(wù)器接收之前這一段的問(wèn)題。
在前端接入層，核心需要解決終端展現(xiàn)時(shí)的響應(yīng)速度和穩(wěn)定性。在傳統(tǒng)的PC互聯(lián)網(wǎng)場(chǎng)景下，大部分產(chǎn)品和應(yīng)用以瀏覽器為終端，通過(guò)網(wǎng)頁(yè)的方式展現(xiàn)在用戶面前，如京東、淘寶等電商類的網(wǎng)頁(yè)版。在終端層面，因?yàn)橛脩粽?qǐng)求量巨大，會(huì)借助頁(yè)面靜態(tài)化、CDN等方式，提升頁(yè)面加載速度。在請(qǐng)求層面，為了提升穩(wěn)定性和應(yīng)對(duì)更大的流量挑戰(zhàn)，在流量進(jìn)入到應(yīng)用服務(wù)器前，會(huì)通過(guò)使用DNS、軟硬件負(fù)載的方式進(jìn)行流量分流，將請(qǐng)求打到不同的應(yīng)用服務(wù)器上。這里會(huì)使用到的硬件負(fù)載有F5等，而軟件負(fù)載主要通過(guò)nginx實(shí)現(xiàn)，早期還有LVS、Haproxy的方案等。
服務(wù)層
說(shuō)完接入層，再來(lái)看服務(wù)層。服務(wù)是應(yīng)用系統(tǒng)的核心，承擔(dān)著業(yè)務(wù)和產(chǎn)品核心需求和邏輯的實(shí)現(xiàn)。
在服務(wù)層，需要解決的重點(diǎn)問(wèn)題問(wèn)題是，服務(wù)是否可以靈活快速的水平擴(kuò)展，以應(yīng)對(duì)未來(lái)系統(tǒng)可能的訪問(wèn)量劇增。
為解決這個(gè)問(wèn)題，需要對(duì)是否進(jìn)行分布式架構(gòu)設(shè)計(jì)進(jìn)行權(quán)衡。分布式架構(gòu)設(shè)計(jì)的核心是通過(guò)對(duì)服務(wù)的解耦，來(lái)解決應(yīng)用的水平擴(kuò)展問(wèn)題，降低單服務(wù)單機(jī)器的壓力。如果系統(tǒng)所需要承擔(dān)的流量在可預(yù)期的未來(lái)會(huì)有較大的增長(zhǎng)，分布式架構(gòu)設(shè)計(jì)就是有必要的。而如果系統(tǒng)流量在很長(zhǎng)一段時(shí)間內(nèi)都相對(duì)有限且平穩(wěn)，則分布式架構(gòu)就顯得沒(méi)那么必要。這里即需要做好平衡和取舍。分布式架構(gòu)雖然能夠帶來(lái)服務(wù)水平擴(kuò)展的便捷性，以應(yīng)對(duì)未來(lái)可能的系統(tǒng)流量大幅增長(zhǎng)，但需要付出較大的系統(tǒng)維護(hù)成本。如果選擇暫時(shí)不采用分布式架構(gòu)，服務(wù)層也同樣可以在工程層面，按照服務(wù)的接口層、服務(wù)的邏輯層和服務(wù)的數(shù)據(jù)層進(jìn)行劃分模塊和子模塊，然后在代碼構(gòu)建打包時(shí)集成到一個(gè)單體應(yīng)用作為一個(gè)jar或war包一起發(fā)布。根據(jù)我之前的經(jīng)驗(yàn)，在一個(gè)業(yè)務(wù)和產(chǎn)品的早期階段，采用模塊化劃分的單體應(yīng)用方式的架構(gòu)，可以快速完成產(chǎn)品MVP版本的上線試錯(cuò)，當(dāng)業(yè)務(wù)發(fā)展到一定規(guī)模后再啟動(dòng)分布式架構(gòu)的服務(wù)化改造，也不失為一個(gè)較好的選擇。無(wú)論在一開(kāi)始就選定分布式架構(gòu)方案，還是在后期做分布式架構(gòu)的服務(wù)化改造時(shí)，都會(huì)面臨著另外一個(gè)選型問(wèn)題：到底是采用分布式服務(wù)還是微服務(wù)方式來(lái)構(gòu)建應(yīng)用。分布式服務(wù)和微服務(wù)是在分布式架構(gòu)演進(jìn)過(guò)程中產(chǎn)生的不同概念，按照我的理解，分布式服務(wù)關(guān)注的重點(diǎn)是分布式，重點(diǎn)解決服務(wù)的壓力負(fù)載分擔(dān)，而微服務(wù)重點(diǎn)關(guān)注的是服務(wù)的單元顆粒度大小，更關(guān)注服務(wù)的原子性、獨(dú)立性。二者都是為了解耦合，但在解耦合的顆粒度上稍有不同。具體的選擇也需要根據(jù)應(yīng)用系統(tǒng)的規(guī)模、領(lǐng)域劃分等綜合考量。落地到分布式服務(wù)的架構(gòu)技術(shù)選型上，有以傳統(tǒng)的RPC框架為主導(dǎo)的技術(shù)體系，和以Spring Boot微服務(wù)框架為基礎(chǔ)的Spring Cloud全家桶。傳統(tǒng)的RPC框架以早期阿里開(kāi)源的Dubbo框架為代表，核心的實(shí)現(xiàn)是基于動(dòng)態(tài)代理+反射的方式來(lái)實(shí)現(xiàn)服務(wù)之間的接口通信，服務(wù)和服務(wù)之間的底層調(diào)用是基于socket來(lái)實(shí)現(xiàn)數(shù)據(jù)傳輸交互的。而Spring Cloud全家桶，核心是基于Http協(xié)議實(shí)現(xiàn)的一套微服務(wù)框架，服務(wù)和服務(wù)之間的調(diào)用是通過(guò)Http接口實(shí)現(xiàn)交互的的。相比Spring Cloud，RPC框架一般具有可自定義數(shù)據(jù)結(jié)構(gòu)、網(wǎng)絡(luò)傳輸速度快、效率高等特點(diǎn)，而Spring?Cloud因?yàn)槭腔贖ttp協(xié)議進(jìn)行網(wǎng)絡(luò)傳輸，消息的包體大小受Http協(xié)議限制做了封裝顯得相對(duì)臃腫，在網(wǎng)絡(luò)傳輸時(shí)效率相對(duì)低一些，但Spring Cloud因有一整套組件和生態(tài)的支撐，因此在不做過(guò)多性能苛求的情況下，也是目前可以快速采用的方案之一。另外一種將二者結(jié)合的方案，利用Spring Cloud設(shè)計(jì)和實(shí)現(xiàn)接口的接入網(wǎng)關(guān)，再通過(guò)網(wǎng)關(guān)將請(qǐng)求轉(zhuǎn)發(fā)到RPC服務(wù)中，則是目前一些大型應(yīng)用普遍采用的方案。在使用Spring Cloud或RPC框架的過(guò)程中，另外一個(gè)需要關(guān)注的問(wèn)題是服務(wù)之間的耦合問(wèn)題。雖然分布式服務(wù)或微服務(wù)本身就是為了解決耦合問(wèn)題，但應(yīng)用和應(yīng)用、服務(wù)與服務(wù)之間的依賴關(guān)系并不因?yàn)槭褂肧pring Cloud或RPC框架就消失了，在一些場(chǎng)景下，適度的服務(wù)之間的依賴是允許且必要的，但過(guò)度的服務(wù)之間依賴，甚至發(fā)展成服務(wù)與服務(wù)之間相互依賴，就是需要避免的一種情況了。通過(guò)消息中間件，將原本有上下游關(guān)系的依賴，通過(guò)消息解耦，從而讓服務(wù)和服務(wù)之間避免強(qiáng)依賴，是其中的一個(gè)解決方案。常用的消息中間件有RabbitMQ、RocketMQ、Kafka等。說(shuō)完服務(wù)層，再來(lái)看數(shù)據(jù)訪問(wèn)層。所有的應(yīng)用都離不開(kāi)數(shù)據(jù)，數(shù)據(jù)是一個(gè)系統(tǒng)的靈魂所在。數(shù)據(jù)訪問(wèn)層主要用于完成服務(wù)層和數(shù)據(jù)存儲(chǔ)層之間數(shù)據(jù)的交互。因?yàn)閿?shù)據(jù)存儲(chǔ)方式的多樣性，數(shù)據(jù)訪問(wèn)層一個(gè)重要功能是實(shí)現(xiàn)對(duì)不同數(shù)據(jù)存儲(chǔ)方式的封裝，盡量做到對(duì)服務(wù)層屏蔽具體的數(shù)據(jù)存儲(chǔ)細(xì)節(jié)。另一個(gè)數(shù)據(jù)訪問(wèn)層的重要作用，是解決數(shù)據(jù)存儲(chǔ)場(chǎng)景下的資源管理問(wèn)題，包括連接池資源、分庫(kù)分表、讀寫(xiě)分離等。具體是否需要做分庫(kù)分表、讀寫(xiě)分離等，需要根據(jù)應(yīng)用的實(shí)際數(shù)據(jù)量大小、選擇的數(shù)據(jù)存儲(chǔ)方式等做綜合考量。最后，再來(lái)考慮數(shù)據(jù)存儲(chǔ)層的搭建和選型。
數(shù)據(jù)存儲(chǔ)層是用于將具體應(yīng)用產(chǎn)生的數(shù)據(jù)持久化。不同的數(shù)據(jù)存儲(chǔ)方式適用的業(yè)務(wù)場(chǎng)景也有很大不同。如對(duì)事務(wù)要比較高，一般采用關(guān)系型數(shù)據(jù)庫(kù)如Mysql、Oracle等；對(duì)數(shù)據(jù)結(jié)構(gòu)和表結(jié)構(gòu)擴(kuò)展性要求較靈活的可以采用NoSQL數(shù)據(jù)庫(kù)如MongoDB、CouchDB等；如果需要存儲(chǔ)的數(shù)據(jù)量非常龐大，可以選擇目前基于hdfs的存儲(chǔ)方案如Hbase、Hive等；還會(huì)有對(duì)文件、圖片等有存儲(chǔ)需求的，可以采用分布式文件存儲(chǔ)或云存儲(chǔ)的方式等。數(shù)據(jù)存儲(chǔ)的方案本身沒(méi)有好壞之分，具體還是要分析業(yè)務(wù)的實(shí)際需求來(lái)做平衡和選擇。
關(guān)于緩存
除了以上所述的幾個(gè)層級(jí)，在大部分互聯(lián)網(wǎng)應(yīng)用中，當(dāng)系統(tǒng)訪問(wèn)用戶量達(dá)到一定量級(jí)，或QPS較高的場(chǎng)景下，還會(huì)通過(guò)增加緩存來(lái)降低系統(tǒng)和接口的響應(yīng)時(shí)間，提升系統(tǒng)的性能。常用的緩存框架有Redis、Memcache等。在架構(gòu)設(shè)計(jì)階段，我們把整個(gè)系統(tǒng)按照分層的思想做拆解說(shuō)明，根據(jù)業(yè)務(wù)的實(shí)際需求，對(duì)各層中采用的技術(shù)和方案做平衡和取舍。架構(gòu)設(shè)計(jì)階段完成并不意味著整個(gè)應(yīng)用系統(tǒng)架構(gòu)的完成。接下來(lái)需要將架構(gòu)設(shè)計(jì)落地到代碼中。
在架構(gòu)設(shè)計(jì)方案完成后，對(duì)于開(kāi)發(fā)工程師來(lái)說(shuō)，已經(jīng)可以根據(jù)架構(gòu)設(shè)計(jì)方案來(lái)指導(dǎo)進(jìn)行詳細(xì)需求設(shè)計(jì)和編碼。對(duì)于架構(gòu)師來(lái)說(shuō)，在這個(gè)階段需要重點(diǎn)關(guān)注的有以下幾點(diǎn)：一個(gè)好的架構(gòu)，一定是需要經(jīng)歷線上系統(tǒng)的檢驗(yàn)的。在測(cè)試人員完成質(zhì)量測(cè)試后，需要對(duì)應(yīng)用系統(tǒng)做上線發(fā)布，進(jìn)入到上線運(yùn)營(yíng)階段。
在上線運(yùn)營(yíng)階段，架構(gòu)師核心職責(zé)是做好各項(xiàng)監(jiān)控和告警指標(biāo)的設(shè)定。
在監(jiān)控層面，首選需要對(duì)應(yīng)用系統(tǒng)相關(guān)的各項(xiàng)性能指標(biāo)做監(jiān)控。通過(guò)一些開(kāi)源或企業(yè)自研的監(jiān)控工具，需要對(duì)應(yīng)用系統(tǒng)所采用的物理資源如磁盤、內(nèi)存、CPU、網(wǎng)絡(luò)等進(jìn)行監(jiān)控；需要對(duì)數(shù)據(jù)存儲(chǔ)組件如數(shù)據(jù)庫(kù)的慢查詢、I/O、庫(kù)大小等進(jìn)行監(jiān)控；對(duì)中間件如RabbitMQ、Redis等讀寫(xiě)、容量等進(jìn)行監(jiān)控；對(duì)應(yīng)用系統(tǒng)性能如接口響應(yīng)時(shí)長(zhǎng)、95線、99線的監(jiān)控等等。
另外一個(gè)重要的監(jiān)控對(duì)象是業(yè)務(wù)指標(biāo)的監(jiān)控，如一段時(shí)間內(nèi)的登陸用戶量、短信發(fā)送量、訂單下單量、訂單支付量等等。業(yè)務(wù)指標(biāo)的監(jiān)控往往能反映出一些系統(tǒng)層面的異常，引導(dǎo)去追究引起業(yè)務(wù)指標(biāo)異常的根本原因，從而提升系統(tǒng)的可靠性和穩(wěn)定性。
具體建立哪些監(jiān)控指標(biāo)需要根據(jù)不同的監(jiān)控對(duì)象進(jìn)行合理的設(shè)定。
建立完監(jiān)控指標(biāo)后，還需要建立告警體系，將異常的指標(biāo)及時(shí)告警通知出來(lái)。一般的監(jiān)控系統(tǒng)都會(huì)有提供類似短信、釘釘?shù)雀婢绞降慕尤搿?/span>
最后，在上線運(yùn)營(yíng)階段還需要收集和關(guān)注系統(tǒng)的日志，及時(shí)排查修復(fù)異常，保障系統(tǒng)的穩(wěn)健運(yùn)行。
以上是從一個(gè)業(yè)務(wù)的需求階段開(kāi)始，到整個(gè)業(yè)務(wù)的應(yīng)用系統(tǒng)上線運(yùn)營(yíng)，作為一個(gè)架構(gòu)師需要關(guān)注的方方面面。
當(dāng)然，其中的每一個(gè)架構(gòu)點(diǎn)和技術(shù)方案，展開(kāi)來(lái)看都是一個(gè)很大的課題。當(dāng)你具備架構(gòu)的全局思維之后，接下來(lái)就可以深入到不同領(lǐng)域?qū)Ｑ校⒃诠ぷ髦胁粩鄬?shí)踐和試錯(cuò)，最終完成自身技能的進(jìn)階。
自計(jì)算機(jī)誕生以來(lái)，各項(xiàng)軟硬件技術(shù)即在不斷迭代更新，催生著軟件架構(gòu)的不斷升級(jí)換代。而隨著大數(shù)據(jù)云計(jì)算5G時(shí)代的帶領(lǐng)，新的業(yè)務(wù)場(chǎng)景如音視頻、直播、物聯(lián)網(wǎng)等等業(yè)務(wù)挑戰(zhàn)也會(huì)隨之而來(lái)，我們對(duì)架構(gòu)的追求也永無(wú)止境。
希望你我都可以在持續(xù)的架構(gòu)演進(jìn)中，不斷學(xué)習(xí)，持續(xù)進(jìn)步。
更多信息請(qǐng)關(guān)注公眾號(hào)：「軟件老王」，關(guān)注不迷路，軟件老王和他的IT朋友們，分享一些他們的技術(shù)見(jiàn)解和生活故事。
