架構師日常（一）
四月伊始，進入新專案擔任架構師角色，幫助專案整理和解決架構方面的問題。在三月技術，完成了前一個專案的工作並進行了交接，基本把手裡需要專案注意的事項都寫成了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的技術實現。