一、前言
架構設計按照實施過程可分為工程架構，業務架構，部署架構等多個維度，一個好的系統架構標準應該具備可擴展、可維護、可靠性、安全性和高性能等特點。盡管這些特點大家都熟知，但在實際落地時，我們更為迫切的想知道實現這些要求的關鍵路徑，以便在架構設計中融入這些特點。只有這樣，才能確保系統能夠適應未來的業務增長和交付效率。本文將重點圍繞如何進行工程架構設計展開探討。
二、價值為先
在方案出現歧義時，站在產品（商業）價值的視角審視方案并作出決策，這一點非常重要。
技術容易陷入的兩個誤區：
- 來者不拒：產品經理提的需求，都是有道理的，我負責完成；
- 技術驅動：這種技術實現特別巧妙，讓產品特性適配于技術實現。
以上兩類誤區，很容易讓研發對產品價值的理解形成偏差，容易對后續的技術迭代產生顛覆性的影響。站在產品（商業）價值維度，能夠讓協作各方站在平等的視角看問題，不僅能夠容易達成共識，也能更好地為業務演進和技術迭代做好規劃。
軟件也是產品，在系統設計的時候，也會圍繞著市場，組織，資源幾個生產要素展開。
- 市場就是我們產品的目標，這是我們的搭建系統的根本；
- 組織就是圍繞著產品交付過程中的資源協調和保障機制；
- 資源就是圍繞著產品投入的機器，人員，時間，運營等生產資料。
軟件開發是圍繞著投入產出比（ROI）展開的生產經營活動。可擴展，可維護，可靠性，安全性，高性能都是我們產品的特性，每一項特性都需要投入相當的成本來實現。
- 跑車速度快，是最突出的特性，它犧牲了路況適應性，乘坐舒適性和駕駛安全性；
- 越野車突出的是路況適應性，它犧牲了速度和舒適性；
- 轎車在路況適應性，乘坐舒適性，駕駛安全性和行駛速度之間做到了相對均衡，成為了常見的代步工具。
正所謂：“將軍趕路，不追小兔”，總是有所取舍。我們不追求打造一個完美的復雜系統，但可以在限定的前提下追求卓越！
三、架構設計
架構模式描述了軟件系統中各個組件之間的關系、職責和交互方式，從而為軟件設計提供了一種規范和約束，進而提高軟件生產效率。主要體現在以下兩個方面：
- 幫助開發人員更好地組織和設計軟件系統；
- 促進團隊之間的協作和溝通，使得團隊成員更容易理解和分工。
1.工程框架
新系統往往從搭建項目的工程基礎框架開始，包括目錄結構、配置文件、代碼模板等工程約束，主要用來規范項目結構、職責邊界和代碼風格，從而提高代碼質量和可維護性。具體包括以下幾個方面：
- 約定了各個模塊的依賴關系和交互方式；
- 規范接口交互協議；
- 統一異常編碼、捕獲和處理；
- 規范日志打印格式；
- 其它公共規范約束。
下面就最常用的分層架構和DDD架構給出一些實踐思路。
1）分層架構
分層架構有多種形式，例如MVC、六邊形架構等，它們是隨著業務和技術的發展逐步演化而來的。
在互聯網初期，由于計算機硬件性能差、網絡速度慢、存儲成本高等因素的限制，互聯網產品的形態相對單一，只能實現簡單的門戶網站、BBS論壇等相對簡單的產品。當時的技術架構沒有分層的概念，主要使用ASP、JSP、php等腳本語言，在這些腳本文件中混合著編寫html、JAVAScript、css和SQL是很常見的。隨著互聯網技術的發展以及更多復雜業務的線上化訴求，動態腳本語言的劣勢也逐漸顯現，以JSP腳本語言為例：
- 復雜性：JSP腳本語言的開發和維護比較復雜，因為需要處理Java代碼和HTML代碼的混合；
- 安全性：JSP腳本語言容易受到SQL注入攻擊等安全漏洞的影響，從而導致系統不穩定或被攻擊；
- 擴展性：腳本語言的可擴展性比較有限，因為需要在HTML頁面中直接編寫Java代碼，從而導致系統結構不夠清晰。
為了解決上述問題，出現了各種框架，如Spring、Struts等。這些框架逐漸替代了JSP腳本語言，同時也提出了分層架構的概念。其中最典型的就是MVC（模型、視圖和控制器）架構模式，其主要目的是解耦應用程序的不同部分，使其更易于維護和擴展。具體實現方式如下：
- 分離關注點：將應用程序分為三個主要部分，使得每個部分都可以獨立開發和測試，從而更好地分離關注點；
- 提高可維護性：因為做了三個層面的關注點分離，更容易維護和修改應用程序的不同部分；
- 提高可擴展性：展示邏輯和業務邏輯控制分離，更容易擴展應用程序的不同部分。
在多層架構中，視圖層通常會使用基于模板的框架（如Thymeleaf、Freemarker、Velocity）或前后端分離的技術棧（如Vue.js、React）。這些技術的演進能夠解決更加復雜的問題，如金融保險和電子商務等場景，但同時也會帶來一些新的痛點：
- 學習曲線較陡峭：由于MVC架構模式需要開發人員了解和掌握多個概念和技術，學習曲線較陡峭；
- 提高了復雜性：由于MVC架構模式需要將應用程序分為多個部分，增加了應用程序的復雜性；
- 增加了開發時間：需要進行更多的測試和集成工作，增加了開發時間。
為了提高產品交付效率并降低技術門檻，現代研發工作通常會拆分為多個崗位，包括前端開發、后端開發、質量測試、運維保障等。這些崗位需要協同工作，共同完成產品的研發任務。為了保證多業務線和多崗位之間的有序協作，有效管控過程風險，通常還會設有項目管理崗位。
MVC架構是對整個業務實現進行了關注點分離，但在更為復雜的大型項目中，特別是多人協作，多業務并行的場景下，MVC架構往往顯得力不從心。此時需要對其進行更細粒度的拆分，以達到多業務線并行，而不會存在大的任務資源沖突問題。當然，不同的業務場景會有不同的拆分模式，最常見的拆分模式是多層架構模式，如下圖：
通過橫向的分層架構我們實現了研發分工協作，所有的經驗約束在這里得以體現。上圖中，將控制層進行了二次細分。也可以按照實際應用場景進行重新調整。比如web模塊能否依賴RPC模塊就可以在POM文件中進行限定，如此一來，大家按照既有的工程約定，實施開發工作就可以了。
簡單描述一下各個模塊分層的作用：
- 數據訪問層：將業務邏輯層和數據存儲層進行解耦，屬于模型層的范疇。它與底層數據源（MySQL、Hbase，EleasicSearch）進行數據交互，常見框架有：MyIbatis，Hibernate等；
- 遠程調用層：即RPC層，與DAO層平行的數據訪問層，區別是它是通過第三方接口或平臺服務提供訪問能力。和DAO層的區別在于數據歸屬權和領域事務控制權；
- 事務管理層：也叫通用業務處理層，它有如下特征:
- 對上層業務，進行業務和技術共用能力下沉，比如：多個業態的統一訂單生產能力，通用的分布式事務一致性的解決方案等；
- 對下層依賴，組合DAO層和RPC層的能力，實現單一業務的事務管理；
- 對于簡單的業務系統，Manager層的職責可以由Service層替代；
- 業務邏輯層：相對具體的業務邏輯服務層，主要負責業務流程的組裝和編排，真正的靈活性和擴展性主要體現在這里；
- 請求處理層：主要是對訪問控制進行轉發，入參整形，出參定制等，其職責是直接面向的是各個終端或第三方服務方；
- 開放服務層：定義對外提供的RPC服務，功能職責和Web層類似，同樣需要考慮網關安全控制、流量控制等因素；
- 終端顯示層：各個端的模板渲染并執行顯示，velocity ，React，IOS移動端等。
傳統的軟件設計往往會導致各個組件之間緊密耦合，從而導致代碼難以維護和擴展。六邊形架構模式是分層模式的一種變體，通過將業務邏輯與框架、庫等技術細節分離，從而實現了松耦合的設計，使得代碼更易于維護和擴展。同時，六邊形架構模式還可以幫助開發人員更好地實現單元測試和集成測試，從而提高軟件質量。這在各種技術中臺性質的業務場景下，非常有用，如下圖：
2）DDD架構
領域驅動設計（DDD）是一種軟件開發方法，它以業務領域為中心，通過深入理解業務領域的知識，將業務邏輯封裝在領域模型中，以此來實現更好的代碼可維護性、可擴展性和可重用性。
DDD屬于松散的分層架構，每層職責和作用如下：
- 用戶接口層：web請求，rpc請求，mq消息等外部輸入請求；
- 應用層：負責編排、轉發、校驗等，這與MVC中的service層中存儲著大量業務邏輯有所不同；
- 領域層：也就是模型層，負責表達業務概念，業務狀態以及業務規則。包含了該領域所有復雜的業務知識抽象和規則定義，包含實體，值對象，聚合（聚合根），領域服務，領域事件，倉儲，工廠等；
- 基礎設施層：為領域模型提供持久化機制及其它通用技術支持能力，如消息通信，通用工具，配置等實現。
為什么DDD常年熱度不減，但在我們實際的系統開發過程中，卻很少有完全落地的項目呢？或者說MVC架構風格的系統很常見，但DDD架構風格的系統卻很少見到。這得回歸到DDD本身：它是解決復雜業務的一種軟件開發方法論。
如果將普通的CRUD業務系統也按照這套模式實現，反而會增加系統的復雜度。總體來說，DDD模式適用于以下幾種場景：
- 支持處理復雜業務邏輯場景：當應用程序需要處理復雜的業務邏輯時，DDD可以將業務邏輯封裝在領域模型中，從而更好地反映業務需求和業務流程，降低了系統架構的復雜度；
- 高度可維護和可擴展性場景：DDD將應用程序拆分成多個子域，每個子域都有自己的領域模型，這樣可以更好地管理業務復雜性；
- 需要快速迭代和交付的場景：每個子域都可以獨立開發、部署和擴展，這樣可以使得團隊可以快速迭代和交付應用程序；
為了評估業務的復雜程度，我們需要從多個方面進行考慮，業務流程、產品規則、數據結構以及需求變化頻率等。一般情況下，采用這種架構模式需要慎重地評估，因為實施這種開發模式會面臨以下幾個挑戰：
- 需要深入理解業務領域：DDD是一種以業務領域為中心的設計方法，因此需要深入理解業務領域的知識，才能設計出符合業務需求的領域模型；
- 需要跨部門協作：實施DDD需要跨部門協作，包括業務人員、開發人員、測試人員等，需要大家共同合作才能達成共識；
- 技術難度較高：DDD需要理解很多復雜的概念，如領域事件、聚合根、領域服務等，需要開發人員具備一定的技術水平。
總之，無論是團隊協作模式、個人技術能力要求、業務共識的達成，各個方面都具有很大的挑戰。但這并不意味著DDD在普通業務系統中，就沒有用武之地。其解決復雜問題的思想仍然能夠讓我們受益。常用的工具框架，如CQRS框架、事件驅動架構和微服務框架，都有DDD的設計思想的影子。
以微服務架構為例，先看以下幾個問題：
- 微服務應該如何設計呢？
- 微服務是根據什么進行拆分的？
- 微服務是如何劃分邊界的？
微服務拆分得太細，更多的服務會提高運營和管理難度；拆得太粗，功能耦合度高，在靈活性和擴展性方面又存在不足。所以這是一個比較棘手的問題。
確定業務和應用邊界，是解決微服務困境的關鍵。而DDD就很好解決了業務邊界的問題，它提供了一種劃分業務領域范圍的方法論。
微服務就是將應用程序拆分成多個子域，每個子域都以微服務的方式對外開放能力。微服務將復雜的業務流程和規則限定在領域范圍內，即內部實現各自的領域模型和數據存儲。從應用層看，這規范并統一了領域服務的實現方式，大大簡化了代碼邏輯，更好地管理了業務復雜性。
2.技術選型
工程架構的搭建除了基礎框架外，還有一部分重要內容，就是各類基礎中間件的選擇，也就是我們常說的技術選型。下面結合示例跟大家展開講述一下，關于技術選型需要關注的要點。
1）業務需求
了解業務需求，明確系統的功能、性能、安全以及未來的擴展需求。
示例：在系統模塊劃分的時候，有的系統會拆分成【WEB 】+ 【JSF微服務】兩組應用進行分開部署，而有的系統只會部署一個【WEB】應用。這中間的判斷標準是什么？拆出來【JSF微服務】的作用是什么？
- 能力復用：微服務層具有更通用的模型設計，具有更強的多業務場景復用的能力。在服務運營的過程中，可以按照業務進行垂直部署；
- 資源隔離：按業務垂直部署，可以更精細化地優化網絡，機器等硬件資源。另一方面，將上層WEB應用與底層的微服務進行資源隔離，同樣可以實現更精細化的資源分配。
綜上所述：如果你的服務沒有多端復用和資源運營的需求，就沒有必要拆開部署，增加調用鏈路和機器資源的多倍投入。反之，進行服務拆分，益處則更大。
2）技術特性
評估不同技術的特性，包括可用性、性能、安全性、可擴展性、可維護性等方面。
示例：曾經遇到過一個系統，底層的存儲層用的是db4o（一款開源的面向對象數據庫），這個中間件擁有很多優點：
- 直接以存對象的方式存取數據；
- 不需要數據庫服務器，只需要一個數據文件，且dll大小僅為300多k；
- 數據查詢，操作簡便且功能強大，甚至不需要使用SQL。
但這里還是不建議使用它，因為我們是分布式集群服務，這個數據庫文件只能存儲在單機上面，即存在單點故障問題，這是最致命的。有時候為了彌補類似的缺陷，你可能需要花費更多的成本。反過來說，如果是作為嵌入式數據庫，應用在某些單片機上，它的這些優勢就能夠顯現出來了。
3）社區支持
考慮技術的社區支持程度，包括是否有活躍的社區、是否有大量的文檔和教程、是否有成熟的第三方庫等。
示例：分布式調度框架中tbschedule算是開源比較早的了，但是開源之后很早就沒有人維護了，如果在普通的業務中輕度使用，應用層做好監控，應該問題不大。但如果是作為基礎中間件大范圍的使用，顯然它在調度過程可觀測性方面，zk重連機制方面，調度異常自動恢復等方面急需升級優化。但現實是社區早就已經停止維護了，這就是一個比較麻煩的事情。
4）團隊技能
根據團隊的技能水平選擇合適的技術，避免使用過于復雜或陌生的技術。這一點非常重要，否則后期的維護成本和迭代效率提升將成為一個大的難題。
示例：Cobol語言是上個世紀70年代，一種被廣泛應用于金融行業的編程語言。它可以處理大量的數據和復雜的計算，而且有著高度的可靠性和安全性。直到2015年，它還運行著全球43%的銀行系統和95%的ATM。
但在2023年3月份，日本就宣布，計劃全部銀行系統Cobol轉JAVA語言。原因就是精通這門古老語言的技術人員非常稀缺,Cobol生態跟不上機器學習、云集成等新的發展了，整個系統的維護成本和迭代效率遠遠低于現代的JAVA生態體系。
5）成本效益
評估不同技術的成本效益，包括開發成本、運維成本、許可證費用等方面。
- 如果有成熟的開源插件可用，我們應該盡量使用它們，而不是重新發明輪子；
- 對于其他團隊已經完成的任務，我們需要考慮是否可以復用。
示例：當前大多數技術中間件都需要JDK8或以上版本的支持，因此在進行技術選型時，我們需要考慮合適的JDK版本。隨著Spring Boot 3的發布，其默認支持的JDK版本為17，不再支持JDK8。這對于新系統而言，選擇新版本似乎更為合適。而對于存量系統，則需要考慮新版本升級對于系統的改造成本以及帶來收益是否匹配，而不是想當然的追求新技術。
6）風險評估
評估不同技術的風險，包括技術成熟度、安全漏洞、依賴關系等方面。
示例：Fastjson是開源JSON解析庫，它可以解析JSON格式的字符串，支持將Java Bean序列化為JSON字符串，也可以從JSON字符串反序列化到JavaBean。具有執行效率高的特點，應用范圍廣泛。現在，在進行技術選型的時候，就需要當心了，原因就是最近兩年它頻繁的爆出安全漏洞，依賴的應用需要跟著頻繁的升級版本，修復漏洞。這還只是表象，更為深層次的原因是顯現出的安全保障方面的不足，這在技術選型時，是不得不考慮的因素。
7）小結
在選擇技術方案時，沒必要對最新的，最熱門的技術抱有執念，綜合考慮業務需求和團隊技能儲備等多重因素，以選擇最適合的方案為宜。當然，為了適應不斷變化的業務需求和技術發展趨勢，也要有及時進行技術評估和更新的意識。
四、規范共識
共識的重要性在于確保團隊成員之間的溝通和理解達成一致。通過制定規范和流程，可以減少重復工作和錯誤，避免沖突和誤解，這有利于提高研發效率和質量。
1.數據分層
1）對象轉換
在分層架構中，各層之間存在相互依賴和引用，數據則通過參數對象進行傳遞。為了確保每一層內部結構的穩定性，我們需要進行防腐設計。這是實現高內聚，低耦合的關鍵。
示例：模型層一張表有20個字段，那么對應的PO對象就有20個屬性。但終端顯示層只要顯示 10 個字段，請求處理層（Web）在獲取數據時，沒有必要把整個 PO 對象傳遞回來，這時我們就可以用只有這10個屬性的DTO對象來傳遞結果到請求處理層，這樣也不會暴露服務端表結構和一些敏感數據。
數據防腐設計常用的手段就是各層定義自己的數據結構，常見的有：
- VO（View Object）：視圖對象，主要對應界面顯示的數據對象；
- DTO（Data Transfer Object）：數據傳輸對象，主要用于遠程調用等需要大量傳輸對象的地方；
- DO（DomAIn Object）：領域對象，就是從現實世界中抽象出來的有形或無形的業務實體；
- PO（Persistent Object）：持久化對象，它跟持久層（通常是數據庫）的數據結構形成對應的映射關系；
在實際的開發中，為了方便起見，不一定需要為每個服務層定義自己的數據對象，可以根據實際情況來靈活處理。例如，在某些簡單的業務場景中，可以跳過DO層對象，直接將PO對象轉換為VO對象。
2）對象復用
在迭代了許久的系統中，很容易碰到一個問題，就是一些對象的作用域失控了，其典型特征有：
- 一個入參對象，有好幾個方法在共用，調整一個屬性值定義，影響范圍大，風險高；
- 直接使用Map容器作為自己服務的入參或出參對象，沒有人能講得清楚容器里面到底有多少內容；
- 一個對象定義里面，存在著多個相似的屬性定義。新的需求來了，為了降低風險，索性就再新定義一個，如此循環往復；
對象的作用范圍失控問題會導致系統整體的穩定性和迭代效率顯著下降。這個問題通常是一個緩慢的積累過程，在不知不覺中形成。其弊端，往往在大的系統調整時集中爆發。
解決此類問題，可以從以下幾個方面入手：
- 預防：在進行架構設計的時候就給出清晰的規范定義；
- 發現：定期進行設計和代碼評審，發現問題后，及時糾正；
- 止損：發現了此類系統，需要考慮微重構，防止持續腐壞下去；
- 復盤：適時對系統進行定期復盤，對好的演進進行鼓勵，對不足的進行引導，養成好的技術氛圍。
2.異常管理
1）捕獲異常
異常捕獲也容易走兩種極端，一種是每個方法都try-catch，一個方法里有多組。另一種是整個鏈路都沒有一個try-catch，處于裸奔的狀態。那么到底該如何進行異常捕獲呢？先看一下捕獲異常的目的：
- 對異常進行預判處理，讓流程得以繼續下去；
- 快速發現并定位問題，保證系統的穩定性。
基于異常處理的目的，對應的處理策略也就清晰了：
- 如果是為了流程繼續下去，那么異常就必須在對應的節點捕獲并處理；
- 如果是為了快速發現定位問題，那么就可以通過在調用入口處進行統一捕獲處理，異常堆棧里會有詳細的異常的原因。
總之，異常是需要捕獲的，但是具體需要在哪里捕獲，如何捕獲，我們可以按照目的進行靈活處理。
2）處理異常
- 業務和系統異常要留有痕跡，方便日后問題定位和統計分析，比如日志，消息等；
- 對各類異常進行有規則的編碼，可以快速定位問題，方便設置應急預案，規則可以參照HTTP的請求響應編碼；
- 打印異常堆棧信息，這是快速定位問題原因的重要手段；
- 對異常數據進行縱向統計和對比，方便識別系統健康狀態。
3.日志管理
- 統一日志框架，建議使用SLF4J日志門面框架，具體實現選擇Log4j2、Logback等；
- 配置日志框架，包括日志輸出格式、輸出位置、輸出級別，輸出方式（異步打印）等；
- 使用不同的級別來記錄不同類型的信息，并分別打印到不同的文件中；
- 定期檢查和清理日志文件，以避免占用過多磁盤空間；
- 根據需要，可以將日志信息發送到其他系統或者進行分析處理，以便更好地監控和管理系統；
- 必要的情況下，建設動態調整日志級別的能力。
4.監控管理
- 系統性能監控：監控系統的CPU、內存、磁盤、網絡等資源的使用情況，以及應用程序的運行狀態。如Nagios、Zabbix；
- 日志監控：監控系統和應用程序的日志信息，引入traceId、業務身份Id，及時發現異常情況。如ELK（Elasticsearch、Logstash、Kibana）；
- 安全監控：監控系統和應用程序的安全狀態，及時發現潛在的安全威脅。如Snort、Suricata；
- 業務監控：監控業務系統的各項指標，訪問量、響應時間、錯誤率等，及時發現業務異常情況。如Grafana、Prometheus；
- 調用鏈路跟蹤：可以跟蹤一個請求在整個分布式系統中的調用鏈路，記錄每個服務節點的處理時間和狀態，并將這些信息聚合起來，形成一個完整的調用鏈路圖，以便于分析和排查問題。如：Zipkin、SkyWalking；
- 監控預警：各種監控工具是輔助快速定位問題的有效途徑，要想第一時間發現問題，完善有效的預警觸達機制必不可少。如郵件，企業微信，短信，電話等。
5.協作共識
1）HTTP服務請求都使用POST方式？
最近，我們的App遇到了一個問題。在某些情況下，服務調用返回了“HTTP 414 URI Too Long”的響應錯誤。這個問題的根本原因是Tomcat默認的get請求長度限制（包括請求行和請求頭）超過了8192個字符。為了解決這個問題，有以下幾種方案：
- 通過修改server.xml文件中的Connector元素中的maxHttpHeaderSize屬性值（比如：改為16384）來放寬限制；
- 將服務的請求協議由只支持GET方式，調整為同時支持POST請求方式，因為POST請求方式沒有這個大小的限制；
- 精簡Header請求參數，規范并限制cookie和業務參數的寫入。
方案一，擴大Tomcat的容器限制，短期看起來可以，但是這是一個公共問題，要調整的應用容器可能需要成千上萬臺，而且治標不治本。
方案二，將所有GET請求方式，調整為同時支持POST請求方式，涉及到的應用又有成百上千個，工作量也不少。
方案三，精簡Header請求參數，這個最為合理和穩妥，也是出現問題的本質原因，但是涉及到兩個APP相互交互以及幾十上百個部門協同梳理和改造，難度同樣很大。
如果是你，該如何選擇方案呢？
2）前端不做邏輯處理，只做數據渲染？
前端視角：由于APP發版，涉及到版本審核，用戶下載更新等流程，一方面周期長，另一方用戶可以拒絕升級。這就導致前端研發提出來，“前端不做業務邏輯處理，只做數據渲染”的口號。如果前端承接了業務邏輯處理，一方面，出了bug，想要修復的代價很高，如果用戶不升級版本甚至無法修復。另一方面，前端承接了部分業務邏輯，將會和后端出現職責邊界難以劃分清楚的情況，給協作埋下了的隱患。
后端視角：一個默認背景圖，一句提示文案，一個字體顏色……這些可預見的不會做出調整的數據，都需要我們來下發嗎？提高了數據復雜度，增加了網絡帶寬。而且前端也有熱更新技術，容易變化的復雜頁面還可以通過H5來實現，怎么就不能做一些簡單的業務邏輯了！
這又該如何進行方案選擇呢？
3）小結
很多技術問題的解決方案并沒有明顯的偏向性，這取決于當時的環境和立場。例如，對于HTTP的GET請求參數超長問題，最合理的解決方案是精簡Header參數，但這需要長期的努力，而在短期內很難實現。因此，在解決當前問題時，我們可以考慮其他兩種方案。同樣地，對于前端是否應該處理業務邏輯的問題，我們需要考慮到我們對APP的定位以及前后端各自基礎能力的建設情況。好方案的評判標準應該是：能夠低成本地解決當前問題，并且不引入新問題。
五、總結
本文詳細介紹了搭建系統工程架構時需要關注的幾個重要方面。基于產品的價值，做出決策，并從系統工程架構的演進、技術方案的選型、系統規范共識的達成等方面入手，對實施過程中的常見問題給出了解決思路。最后，借用《楞伽經》中的“標月指”作為結束語，與讀者共勉：“如愚見指月，觀指不觀月。記著名字者，不見我真實。”
作者丨劉慧卿
來源丨公眾號：京東云開發者（ID：JDT_Developers）
