架構師日常（一）

四月伊始，進入新項目擔任架構師角色，幫助項目整理和解決架構方面的問題。在三月技術，完成了前一個項目的工作並進行了交接，基本把手里需要項目注意的事項都寫成了Markdown文檔，記錄在了Azure DevOps Wiki中，分門別類供團隊成員查閱搜索。這里必須提到團隊的知識管理，有一個可以及時更新並且能進行搜索的Wiki是很重要的，架構上的很多內容如果無法通過架構文檔更新就應該提現到團隊的Wiki中，已供涉眾（包括客戶方團隊和運維團隊，不僅限於開發團隊）參考，並且可供后期架構文檔更新提供素材。

新的項目領域為供應鏈管理（SCM, Supply Chain Management）或供應商管理（SM, Supplier Management），大致瀏覽一下網上關於供應鏈管理所需要的能力，包括：

• 平台能力：包括分析、繼承、個性化等；
• 供應商管理運維模型：包括供應商績效管理、供應商關系管理、供應商風險和合規性、供應商激勵等；
• 供應商生命周期管理（工作流）：包括供應商開發、供應商監控和智能化、風險管理、供應商注冊、戰略溯源、供應商分類、供應商登記、供應商協作、沖突解決、供應商度量等；
• 供應商信息管理：包括綱要、元數據、權限、集成、表單和規則、外部內容、自服務、分析等；
  內容還挺多，為了快速成為供應商領域的架構師看來得動用萬能的某寶或某東了，在網上迅速選了兩本最新跟供應鏈管理相關的書籍，當然內容也要跟架構和時下流行的數字化搭上關系，所以選擇了《供應鏈架構師——從戰略到運營》《數字化供應鏈》這兩本，迅速下單估計周內就能到手，對於剛進入項目至少需要2周搞清狀況的架構師，1周時間閱讀行業相關內容是綽綽有余了。

行業內容大致有了把握，接下來就是對現有系統的分析。包括從組織架構、系統集成和系統涉眾三個方面：

• 組織結構指的是開發、運維這邊的組織結構，可以查閱應用在內網的相關信息，通過聊天獲取團隊組成結構的情報。這個項目是一個敏捷項目，項目集采用SAFe框架進行管理，每個獨立子項有相應的Scrum Master（團隊敏捷教練）、Product Owner/Business Analyst（產品擁有者/業務分析師，一般對接客戶團隊，幫助澄清需求）、Technology Architect（技術架構師，設計和實現技術架構），為了實現產品化開發還有Product Manager（產品經理，控制產品化開發流程），在整個項目集上還有Portfolio/Program Manager（項目集經理，統管項目集），在組織級別或稱Delivery Lead，還因為運行SAFe，有RTE(Release Train Engineer，發布訓練工程師？因為對SAFe了解不深，這個稱呼第一次聽說，不過項目里這個人我倒是很熟悉)。熟悉各個角色的人之后方便我們溝通，具體問題找合適的人，比如業務問題找BA或測試人員，技術問題找架構師或Tech Lead，項目資源問題找SM或PM等等。
• 系統集成方面，要了解上下游系統之間的關系，調用關系、數據流等，也要了解各系統所屬項目集以及管轄團隊，方便需要了解相關背景的時候能夠問到合適的人。對於所有集成點，要了解使用的協議（HTTP/HTTPS）、方法（GET/POST）、架構樣式（API/Event Driven）等等，如果調用了單點登錄或者OAuth，要拿到相關的Credential方便我們去調用、測試；如果是Web應用，就應該讓團隊給我們加權限，以便我們能夠訪問系統了解系統的用途。
• 系統涉眾，要清楚系統的客戶是誰，我們在為誰工作，為誰創造價值；還要知道用戶是誰，他們是如何使用系統，與系統進行交互的。
  以上三點是整個2周我們要弄清楚的東西，但不能着急，首先要從項目相關的信息入手，了解項目的背景、目的，要實現大致業務功能，了解系統在流程中的位置，都有哪些用戶，用系統主要要解決什么問題等。

中間抽空還是找項目的技術架構師和SM聊聊，多少先去了解項目有哪些問題，畢竟空降架構師一般都是為了解決項目中比較棘手的問題，根據四象限原則要么是重要的，要么是緊急的。那么我們先了解一下亟待解決的問題吧。原來上個月該項目已經參加了公司的架構評審組的評審會，架構評審委員會給出了以下的建議：

• 要清楚的數據模型，方便了解系統；
• 要清楚集成點；
• 現在NoSQL數據庫的使用方式比較奇怪，建議部分數據使用關系型數據庫；
• 多語言組件需要開源組件審核團隊的批准；
• 代碼模板應該使用公司通用的代碼模板；
• 認證審核方面應該增加與公司級訪問控制平台的集成；
• 微服務方面沒有實現每個服務使用獨立的數據庫；
• 部分容器化服務是否可以考慮使用無服務（函數即服務）的架構風格；
• 報表系統應該使用公司的數據湖和統一的報表系統；
• 集成的幾個子系統之間應該使用統一的通用ID來標識數據，這樣可以保證數據的唯一性；
• 對於計算服務是否能采用低碳區域雲服務以達到節能減排可持續發展的目的？

那我們就一個一個問題來拆解：

• 問題1：要清楚的數據模型，方便了解系統。
  這個問題我們需要創建三個文檔來解決架構評審委員會的疑問，為了能把數據模型解釋得清楚明白，我們就需要最基本的三個關於數據的文檔，Conceptual Data Model概念數據模型、Logical Data Model邏輯數據模型和Physical Data Model物理數據模型。
  其中，概念數據模型只標識到實體或者值對象級別，線框圖的框中基本都是數據實體或值對象的對象名稱，沒有細化到它的屬性或字段。為的是突出系統需要哪些數據實體參與，實體之間是怎樣的關系，是1對多還是多對1或者多對多，當然也有1對1的情況，還有0或者1對1或對多的情況。
  而概念模型就要細化一些實體的屬性，讓我們能了解如何收集、管理和使用這些數據。最后就是物理模型，是能直接表現出在關系型數據庫或者非關系型數據庫例如NoSQL數據庫中如何定義和存儲這些數據。

• 問題2：搞清集成點。
  最簡單的方法就是畫架構圖，要清晰、要將上下文都呈現出來。有哪些上下游系統如何交互，有哪些系統用戶，有哪些數據流轉，主要使用哪些服務或者組件，都要清晰，這樣在討論的時候才能搞清楚問題。這部分跟我們上面提到的分析系統要分析系統的客戶、用戶和涉眾以及上下游系統是沒什么分別的。這可能也是今天要跟團隊做的主要部分。

• 問題3：現在NoSQL數據庫的使用方式比較奇怪，建議部分數據使用關系型數據庫；
  因為前期開發系統的目標主要為創建一個調查問卷系統用於評估供應商，但久而久之隨着需求的擴大，就需要管理許多關系型數據，如層級結構的數據、需要聯合查詢的數據，這部分數據是不太適合NoSQL數據庫的。因為你從NoSQL數據庫進行聯合查詢的性能極低，要么是先取出主表數據，然后根據主表數據分別查找子表數據，而且很多需要關聯查詢的地方要很多復合的條件，如果要在NoSQL數據庫實現，就需要創建很多的索引，會降低NoSQL的數據訪問性能。這部分可以考慮將關系型數據庫遷出NoSQL數據庫，使用內存型緩存數據庫和關系型數據庫的方式進行緩存和存儲，提高訪問性能。

• 問題4：多語言組件需要開源組件審核團隊的批准；
  這個比較好解決，注意許可問題，然后找開源組件審核團隊批准就可以了。

• 問題5：代碼模板應該使用公司通用的代碼模板；
  這種屬於合規性問題，基本只需要照着做就可以了，當然我們也會考慮公司代碼模板可能有部分無法實現和滿足需求，這里我們可以做一個融合。如果是基礎類，那么我們可以繼承公司模板的基礎類然后用我們自己定義的基礎類再封裝一層讓業務邏輯或者實體進行繼承，如果是輔助類或者工具類方法則可以直接進行使用或者調用，當然如果能使用公司模板中的方法盡量不要二次造輪子自己開發。

• 問題6：認證審核方面應該增加與公司級訪問控制平台的集成；
  這是認證、審核管理的問題。公司統一的訪問控制平台提供了集中式管理的能力，這點我們還是要使用公司級的平台和系統，因為它們的集中式管理運維可以幫助我們節省日后的更新或者配置出現的問題和麻煩。

• 問題7：微服務方面沒有實現每個服務使用獨立的數據庫；
  微服務有很多模式，不同的模式解決的問題也不盡相同，不過對於微服務我們更多的考慮隔離性，通過不同的邊界上下文、不同領域（不同的業務能力或者業務領域）進行划分，從物理和邏輯兩個層面解耦，這是微服務的核心訴求，所以要考慮盡可能的符合基本的模式，如Database per Service或者Saga。

• 問題8：部分容器化服務是否可以考慮使用無服務（函數即服務）的架構風格；
  雖然這已經是最大的變化了，從容器到無服務計算，基本就是Re-Arch而不僅僅是Re-Platform或者Re-Factor。雖然成本大，付出高，但是這樣做的未來收益很多，因為不必再考慮可擴展性和可用性的技術性需求，因為函數即服務都可以滿足。當然，無服務計算不是銀彈，如果有諸如需要大量內存或者本地存儲，高性能計算，長時間后台運算或者組件需要操作系統接口進行安裝等要求的時候就無法使用無服務計算，所以可以先對現有服務進行評估再行決定。

• 問題9：報表系統應該使用公司的數據湖和統一的報表系統；
  贊成，但需要看報表需求究竟真的只是報表功能，還是只是數據的“導出”功能，另外與數據湖集成我們也要考慮數據延遲，我們的報表需求是否有即時或者接近實時（Near Real Time）輸出的需求等等。

• 問題10：集成的幾個子系統之間應該使用統一的通用ID來標識數據，這樣可以保證數據的唯一性；
  贊成，業務方面我們最好在相近功能的子系統間維護統一的數據標識，同樣的，對於一次會話或者連續調用的多個API之間或者微服務之間我們也應該使用類似的CorrelationID來關聯所有的操作日志，以保證我們的數據也好日志也罷在大批量數據查看的過程中能體現出連續性和一致性。

• 問題11：對於計算服務是否能采用低碳區域雲服務以達到節能減排可持續發展的目的？
  這個是為了實現碳中和、可持續發展的目標，我們還是要支持的。

解決了架構的基本問題，我就開始看代碼，因為項目的Azure DevOps的代碼倉庫中一共有29個代碼倉庫（Code Repository），我就從頭到尾看了一遍，發現有幾種情況：

• 項目采用JavaScript或TypeScript或Java或Python，實現自動化測試為目的的代碼倉庫；
• 項目使用JavaScript或Python，實現區塊鏈核心的代碼倉庫；
• 項目使用TypeScript，實現頁面前后台的代碼倉庫；
• 實現Terraform，以代碼實現基礎設施配置的代碼倉庫；
• 實驗性項目的代碼倉庫；
• 空的無用的代碼倉庫；

對於后兩種代碼倉庫可以刪除或者另行保存，防止對開發人員的干擾，另外需要按區塊鏈核心、業務前后台合、測試、基礎設施配置等並為同一代碼倉庫，采用同MonoRepo的理念，設計一個代碼的組成結構，這樣能保證開發人員得到的所有代碼都是一致的，而且可以和當前開發的Sprint（敏捷中的階段，也叫沖刺）對應。

因為是既有項目，很多業務都是測試人員更新測試Case或者重新編寫業務說明文檔，有時候有文檔更新不及時的情況。這里比較推薦使用BDD（Behavior Driven Design，行為驅動設計），它使用Gherkin語法（Given, When, Then）描述輸入和期待的輸出行為，可以作為業務說明文檔使用，而且也有相結合的活文檔工具，通過BDD測試結果標識哪些場景已經通過測試並可以被使用。這部分還屬於項目要試驗的部分。

另外因為主要業務邏輯還有前台都是使用TypeScript或者JavaScript實現的，正好跟我前端時間研究的TypeScript生態有交集。可以使用nvm（Node版本管理器）、yarn（比npm更快的包管理器）、ESLint（代碼靜態檢查工具）、Prettier（代碼格式化工具）、Husky（Git提交鈎子程序）以及Cucumber.js（BDD測試工具）等加速開發，減少提交后的代碼檢查（Code Review）工作，把靜態代碼檢查測試能工作都留到提交前完成。

另外兩個系統之間的數據同步集成可以考慮使用最新的Data Fabric的技術實現。