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