一起學習下架構的視角。
架構的視角
在筆者的知識體系中，實際上將架構分爲業務架構、應用架構、雲基礎架構這幾大類，業務架構主要着眼於控制業務的複雜性，基礎架構着眼於解決分佈式系統中存在的一系列問題。無論何種架構，都希望能實現系統的可變的同時保障業務的高可用。
-
很多時候架構的視角/分類沒有明顯的邊界，通常是交叉的； -
有意思的是，軟件架構及其視角往往和它所在的部門組織架構有着直接關係。@pdai
業務架構
核心是解決業務帶來的系統複雜性，瞭解客戶/業務方的痛點，項目定義，現有環境；梳理高階需求和非功能性需求，進行問題域劃分與領域建模等工作；溝通，方案建議，多次迭代，交付總體架構。
看看京東業務架構（網上分享圖）：
應用/技術架構
根據業務場景的需要，設計應用的層次結構，制定應用規範、定義接口和數據交互協議等。並儘量將應用的複雜度控制在一個可以接受的水平，從而在快速的支撐業務發展的同時，在保證系統的可用性和可維護性的同時，確保應用滿足非功能屬性要求（性能、安全、穩定性等）。技術架構主要考慮系統的非功能性特徵，對系統的高可用、高性能、擴展、安全、伸縮性、簡潔等做系統級的把握。
不限於如下視角，主要表示應用開發中的軟件架構視角...
視角：功能視角
功能視角和業務視角有重合的地方，主要針對開發而言的服務功能；
視角：技術視角-總體
技術框架（technological Framework）是整個或部分技術系統的可重用設計，表現爲一組抽象構件及構件實例間交互的方法;另一種定義認爲，技術框架是可被技術開發者定製的應用骨架。前者是從應用方面而後者是從目的方面給出的定義。
從技術層面描述，主要是分層模型，例如持久層、數據層、邏輯層、應用層、表現層等，然後每層使用什麼技術框架，例如Spring、hibernate、ioc、MVC、成熟的類庫、中間件、WebService等，分別說明，要求這些技術能夠將整個系統的主要實現概括。
視角：技術視角-數據架構
專注於構建數據中臺，統一數據定義規範，標準化數據表達，形成有效易維護的數據資產。打造統一的大數據處理平臺，包括數據可視化運營平臺、數據共享平臺、數據權限管理平臺等。
視角：技術視角-基礎架構
PAAS，IAAS...
視角：技術視角-運維架構
負責運維繫統的規劃、選型、部署上線，建立規範化的運維體系。
物理架構
物理架構關注軟件元件是如何放到硬件上的，專注於基礎設施，某種軟硬件體系，甚至雲平臺，包括機房搭建、網絡拓撲結構，網絡分流器、代理服務器、Web 服務器、應用服務器、報表服務器、整合服務器、存儲服務器和主機等。
以一個銀行系統爲例
下面爲業務性能及網絡性能監控的物理部署架構圖，分網絡接入層和匯聚層兩個層次對網絡流量報文進行捕獲和深入分析。
物理部署架構設計說明：
-
（1）通過4臺TAP設備獲取青山湖和艾溪湖兩個數據中心、五個機房相關應用服務器接入交換機的鏡像流量，並進行規則過濾； -
（2）通過1臺高性能匯聚TAP來獲取艾溪湖數據中心二層匯聚交換機和核心交換機的鏡像流量，並進行規則過濾； -
（3）艾溪湖主數據中心各機房接入層TAP設備的流量共享給匯聚TAP設備； -
（4）BPC系統的5臺BPC服務器在兩個數據中心的每個機房進行分佈式部署、解碼和分析，並集中展示； -
（5）NPM系統在艾溪湖數據中心部署一臺管理端服務器，並在每個數據中心各部署一臺NPM探針服務器，通過分佈式部署、捕獲數據，集中監控展示的方式，監控兩個數據中心的各業務系統的網絡性能； -
（6）通過雙數據中心、多機房分佈式部署的方式，端到端的監控業務在各個環節的流轉情況，實時監控，快速定位。
下面爲運維大數據平臺的物理部署拓撲圖，分爲三個集羣，Hadoop集羣、ES日誌集羣和Kalfka消息集羣。
物理部署架構設計說明：
-
配置多臺服務器做Hadoop集羣，滿足不同應用和系統日誌的單系統與跨系統交易日誌統計與分析，滿足數千個基礎監控分區的基礎性能分析與運行性能指標預測等，以及指性能標入庫與歷史日誌數據入庫的存儲需要。 -
配置多臺服務器做ES集羣，承載實時統一日誌查詢與分析平臺的任務，滿足數天至一個月不同需求的日誌查詢和分析需求，歷史日誌查詢需要從HDFS中將數據導入至ES中，進行二次查詢。 -
配置多臺服務器做Kafka集羣用於實時的指標型與日誌型數據流的採集，滿足實時監控的需求。
DDD到各種架構
領域驅動設計的戰略核心即是將問題域與應用架構相剝離，將業務語義顯現化，把原先晦澀難懂的業務算法邏輯，通過領域對象（Domain Object），統一語言（Ubiquitous Language）轉化爲領域概念清晰的顯性化表達出來。
-
統一語言，軟件的開發人員/使用人員都使用同一套語言，即對某個概念，名詞的認知是統一的，建立清晰的業務模型，形成統一的業務語義。將模型作爲語言的支柱。確保團隊在內部的所有交流中，代碼中，畫圖，寫東西，特別是講話的時候都要使用這種語言。例如賬號，轉賬，透支策略，這些都是非常重要的領域概念，如果這些命名都和我們日常討論以及 PRD 中的描述保持一致，將會極大提升代碼的可讀性，減少認知成本。。比如不再會有人在會議中對“工單”、“審覈單”、“表單”而反覆確認含義了，DDD 的模型建立不會被 DB 所綁架。
-
面向領域，業務語義顯性化，以領域去思考問題，而不是模塊。將隱式的業務邏輯從一推 if-else 裏面抽取出來，用通用語言去命名、去寫代碼、去擴展，讓其變成顯示概念；很多重要的業務概念，按照事務腳本的寫法，其含義完全淹沒在代碼邏輯中沒有突顯出來。
-
職責劃分，根據實際業務合理劃分模型，模型之間依賴結構和邊界更加清晰，避免了混亂的依賴關係，進而增加可讀性、可維護性；單一職責，模型只關注自身的本職工作，避免“越權”而導致混亂的調用關係。通過建模，更好的表達現實世界中的複雜業務，隨着時間的發展，不斷增加系統對實際業務的沉澱，也將更好的通過清晰的代碼描述業務邏輯，模型的內聚增加了系統的高度模塊化，提升代碼的可重用性，對比傳統三層模式中，很有可能大量重複的功能散落在各個 Service 內部。
參考文章
-
https://blog.csdn.net/wxyyxc1992/article/details/100129049 -
https://baijiahao.baidu.com/s?id=1608647829654152773&wfr=spider&for=pc -
https://blog.csdn.net/zhangbijun1230/article/details/81979535 -
https://blog.csdn.net/ITLearnHall/article/details/82985480 -
http://www.talkwithtrend.com/Article/243093 -
https://segmentfault.com/a/1190000020220143 著作權歸@pdai所有 -
原文鏈接：https://pdai.tech/md/arch/arch-x-view.html
作者|頂尖架構師棧