在過去的兩年時間裡，我加入了一家傳統行業的企業參與其數字化轉型的過程，現在我將我的經歷分享出來，本文是第二部分—技術篇，主要會介紹一下我所在的技術團隊實踐的技術架構和體系，用到了哪些元件，以及一些心得感受。

上一篇：預告篇 - 介紹了數字化轉型的背景以及什麼是數字化轉型

1、簡單說說我司是幹啥的

記得有位大佬說“一切拋開業務而談技術的架構，都是耍流氓”，對，他就是玄姐。

玄姐說：架構需要服務於業務，針對不同的業務場景架構設計也會不同，架構設計不必追求高大上，簡而美的架構，若能滿足業務發展需求，便是好架構。

本來想在業務篇再介紹一下業務，但是發現只談技術好像不解釋一下業務背景，本篇很難說下去。因此，這裡我首先簡單地介紹一下我司的業務吧。

我司是天府之國本土一家家裝公司，這裡暫且叫它X公司。家裝行業屬於大居住領域的一個子域，而大居住領域屬於衣食住行的“住”方向上。美好的居住環境是人類永恆的追求，同時也是人類財富的最大載體。尤其是我們這些城市的居民，我們大部分人的時間其實都是在室內度過的，所以X公司的slogan叫做“創造更好的生活，To a better life.”，朝著解決客戶家裝過程的體驗的痛點出發，為客戶營造一個更好的家。

X公司的業務包括了三大部分：精裝、軟裝 和 定製櫃體。如果有裝修過自己家房子的童鞋應該都知道，精裝就是基裝，也就是鏟牆、水電、吊頂、防水、鋪磚、衛浴等一些列操作的合集。軟裝則是在基裝的基礎上為你的房子增添一下匹配的沙發、床、餐桌、椅子、地毯、燈具，讓你可以拎包入住了。定製櫃體則是讓你的衣櫃、鞋櫃、吊櫃等於你的房子100%的match並且還好看，這一點是標品櫃子無法實現的功能，當然這也是一般家裝公司和客戶的標配選擇。

2018年，X公司開始重視資訊化、數字化的建設，也就有了2年前我從一家做保險的外企跳槽到X公司的經歷。其實，大一點的家裝企業早在幾年前就已經開始重視數字化建設了，但能夠持續投資進行數字化建設的家裝企業並不多。這兩年裡，我和我的同事們從0到1構建了公司數字化平臺的雛形和初期的技術架構。

2、總體技術體系與架構

在進入X公司後，我的領導便規劃了資訊科技中心的目標是“為業務插上體驗和效率的數字化翅膀”，體驗和效率是所有傳統行業在提供服務上的短板，而技術團隊需要做的是通過對業務的數字化改造實現公司的數字化轉型，從而趕上網際網路時代的步伐。

有了目標，那也得有抓手，我的領導選擇的是構建一個適合X公司的數字化平臺，可以服務公司各個核心業務和支撐業務的運營和協作。

平臺化思維也是大多數傳統行業進行數字化轉型的一個重要思路和方法，平臺化意味著協同、公開和共享，是需要站在整個企業的高度去思考和規劃的。因此，我的領導們就在前期做了很多這樣的思考和規劃，交給我們技術團隊的就是逐步去實現這個數字化平臺。

我們最終選擇瞭如下圖所示的技術體系，這也是一個比較通用的具有微服務架構風格的技術體系。

• 在展示層，我們使用到的技術主要是React、Vue 以及 Flutter。React主要用開發業務管理後臺系統、Vue主要開發to C/B端的商城、H5以及業務系統，而Flutter主要開發to C/B端的App。

• 接入層使用的是Nginx做反向代理和API閘道器的負載均衡。

• 閘道器層使用的是Ocelot（一個基於.NET Core開發的閘道器開源專案）開發的API閘道器，用以前端應用的統一接入，它還集成了鑑權、認證、限流等功能。這裡區分了內部應用閘道器（即自己開發的前端應用）以及外部應用閘道器（即第三方應用 或 未來開放平臺對外支援的應用）。

• 聚合服務層也就是我們所說的BFF（Backend For Frontend），是每個具體系統的後端API服務，他們大部分使用的ASP.NET Core開發的WebApi，小部分是使用Golang開發的WebApi（部分同事對Golang比較感興趣，因此在BFF層的新Api專案做了一些嘗試和實踐）。所有的BFF都需要帶上合法的token才能正常呼叫。當然，這一層的業務比較少，主要就是呼叫業務服務層的多個業務服務進行聚合，然後返回給前端應用。

• 業務服務層也就是我們常說的微服務了，像客戶服務、訂單服務之類的都在這一層次，它們是公司業務能力的整合，也是數字化平臺的重要組成部分。

• 支撐元件層是一些通用的基礎元件或服務，比如服務註冊和發現、日誌管理、Job、配置中心、容器平臺等等。

• 基礎設施層主要是伺服器的資源，對於我們來說，計算、儲存、網路三大部分的基礎設施目前都已經上雲了。嗯，我們選擇的是阿里雲。

• 其實按照目前主流的做法，在支撐元件層和基礎設施層之間還有一層平臺服務層，容器雲平臺就應該在這一層，不過我們暫時沒有，也就沒有考慮。

跟著這個技術體系，到目前為止我們逐步了一個實現如下圖所示的總體架構，也有了一點領導當初設想的平臺的樣子。

在展示層，我們的前端應用目前已經有官網、商城SPA & H5，公眾號、小程式、用於設計師設計專案交付的Web系統、用於營銷員業務的App、用於工程施工專案管理的App、全業務流程的後端管理系統等，未來如果有可能，還可能會開放自身的介面能力提供給第三方合作伙伴。

在BFF層，我們針對各個前端應用開發了對應的API服務，當然，這一層的API沒有多少業務邏輯，主要是做介面呼叫和資料聚合。而所有的BFF呼叫中臺服務，都是走的另一個API閘道器，這個API閘道器是部署在內網的一個專門給BFF呼叫的閘道器，目前我們沒有給它設定鑑權等功能，單純地做請求轉發。而所有前端應用預設只和BFF通訊，因此他們只會走接入閘道器，必須帶合法的token才能訪問。

在核心業務服務層，相信大家也都可以看到核心部分就在此，這些微服務是為平臺而整合和構建的核心業務服務，它們是在這兩年多的開發中逐漸演化抽象出來的，當然裡面部分服務尚在開發之中，但已經顯現了雛形。而通用的支撐服務則使得業務服務的開發人員不再需要關注非業務部分的程式碼編寫，比如使用Identity Server 4開發的認證和許可權中心，使用Hangfire開發的的統一Job中心，能夠傳送Email、App推送（極光推送）、簡訊（阿里雲簡訊服務）等訊息的通知中心，整合第三方支付的統一支付中心，使用Consul的服務註冊中心，使用CAP+RabbitMQ的事件匯流排等等。

目前，我們所有的微服務之間的通訊都是走的REST，使用的WebApiClient這個元件，它類似於Spring Cloud中的Feign，是一個宣告式的Http呼叫元件，非常好用，而且易於做單元測試。當然，目前量還很小，即使不走RPC，也還是可以接受的。以後量大了後，可能會對部分核心業務的使用GRPC。

有了核心業務服務和支撐服務，我不得不想起這其實就對應了所謂的中臺。中臺的非標準定義就是“企業級能力複用平臺”，而客戶、內容、訂單、設計交付、工程交付等就是X公司的核心業務能力，這些服務面向不斷擴張的服務於各個變化場景的前端應用（比如新增一個拼多多的營銷渠道應用接入，某個新應用需要使用到客戶資料進行分析，某個App又需要看到工程施工的全流程和現場圖等等等等）提供可複用的能力。

在日誌管理方面，我們主要使用一臺獨立的阿里雲伺服器搭建的Exceptionless日誌平臺，在越來越多的微服務下檢視日誌變得還是很方便。

在持續整合方面，我們主要使用的是Jenkins+一堆外掛搭建的持續整合平臺，可以實現某個業務領域相關的專案比如從Web、App（Android）到API的面向多個環境的（DEV、SIT、UAT、STAGE）持續部署到Linux伺服器的構建。目前也實現了基於.NET Core的持續整合構建，包括拉取git程式碼到編譯到單元測試（xUnit）再到自動化介面測試（Python編寫）的流水線。對於這一塊，如果有預算，建議直接上雲服務，比如Azure DevOps這種服務平臺，可以節省很多時間和精力。

畫外音：不得不說，開發之餘，為Service編寫完善的單元測試還是很有必要的，可以提高check-in的信心，這是部分程式碼質量的保證啊。 

在容器化方面，我們主要使用的是Docker + Compose。一來Compose比較簡單易用，可以滿足現有的Ops需求；二來Kubernetes基於目前團隊的技術和運維水平自建不靠譜，上雲服務今年疫情之下公司成本又不允許我們搞；所以，我們目前主要是基於Compose在Jenkins做了一套持續釋出的構建任務，包括拉取程式碼、打映象再到批量部署一系列的流程。

畫外音：原本計劃是今年上阿里雲ACK服務（K8s服務），但是成本預算和各種限制條件實在不允許，因此考慮到Compose也可以滿足未來半年的需求，就沒有再繼續調研了。畢竟，在滿足現有業務的前提下，簡單易用，就是符合團隊的。

3、一些感想

演進源頭：單體 or 微服務 ？

這是一個沒有標準答案的問題，很多業界大佬也都對此有各自不同的看法。而我們在一開始就採用了微服務，一是在之前做了一些.NET Core微服務PoC的驗證，二是我們沒有多少現有的遺留系統便於從0開始演進，最後也是領導的“強烈”要求。

但是，我還是建議，在技術團隊的人員水平、技術儲備（特別是服務治理和運維水平） 以及 業務發展不明確的初期，選擇 模組化的單體 進行演進可能會更好。

模組化的單體架構的專案代表可以參考SimplCommerce 和 ABP，它們都可以實現主程可以按功能拆分成N個平行的小模組，這樣每位開發成員都清楚自己負責的模組。畢竟，新人是專案開發中最具破壞力的元凶之一，模組間獨立、隔離可以有效的限制他們，避免核心模組或整體汙染。最終實現，看起來是微服務，但其實還是一個單體。

SimpleCommerce：https://github.com/simplcommerce/SimplCommerce

ABP的話我不太瞭解，建議自行查閱相關資料，比如張隊，比如樑老闆。

在持續的演進過程中，可以將核心模組進行拆分，形成一個獨立的微服務進行開發和部署。

推薦大家也可以去看看康威定律，微服務中很多核心理念其實在半個世紀前的這篇康威定律的文章中就被闡述過了，而且這篇文章中的很多論點在軟體開發飛速發展的這半個世紀中竟然一再被驗證。

用通俗的說法康威定律的第一定律就是：組織形式等同系統設計。當你猶豫不決的時候，不妨去看看它。

服務設計：DDD or 其他 ？

可能大家聽說微服務最好的設計方法論是DDD，沒錯，正是微服務讓DDD煥發了第二春，DDD也確實是微服務的最佳實踐方法論。

但是，DDD的學習成本較高，技術團隊裡面需要有一個人是DDD非常熟悉的人，還需要有一個業務專家（這個業務專家可以是業務部門的人，但是，對於傳統行業的企業來說，很難培養），對於我們團隊來說，不具備這個條件，雖然我們也在努力的學習DDD，但是，你懂的，這個時間對於發展期的企業太寶貴，還是應該將資源重點先投入到業務的線上化上。

因此，我們沒有采用DDD，程式碼層面也是簡單的三層架構，因為，所有人都可以快速上手進行開發和維護，沒有什麼比快速上手更好的了。但是，快速上手節省出來的時間可不能浪費，針對Service的單元測試需要補上和完善，才能夠保證CI任務的執行效率。

當然，現在沒用DDD，不代表以後不用，可能我的同事們以後就會用DDD了。

基礎設施：有預算能上雲的儘量上雲

對於傳統行業企業的資訊科技團隊，一般來說人員配備即使很齊，但是技術儲備都不夠完善，大多數都沒有大型網際網路公司的經歷，更別說像我們團隊一樣沒有一個運維/DevOps人員。因此，建議所有的基礎設施如伺服器資源（比如阿里雲ECS）、儲存資源（比如阿里雲OSS+CDN）、資料庫資源（比如阿里雲RDS）以及負載均衡（比如阿里雲SLB）、容器編排（比如阿里雲ACK）等基礎服務和平臺服務都儘量上雲，可以幫助團隊減少聚焦點從而把更多的精力留在核心業務的線上化上，也可以減少這些非業務的技術工作佔據太多的時間以及生產問題。

當然，上雲的前提還是成本預算，有預算的話，儘量選型成熟的雲服務。目前我們選擇的雲服務有：阿里雲伺服器ECS、阿里雲OSS+CDN、阿里雲MySql服務RDS、阿里雲簡訊服務、阿里雲域名與證書SSL服務、阿里雲效能測試服務等。

畫外音：當然，有人會說全部用雲服務，豈不是不能很好的鍛鍊自己的技術？但是，你有沒有想過自研框架出問題的時候，你會有多崩潰。站在企業級的高度來看，技術是為企業的業務發展服務的，因此需要平衡投入與產出，

遺留系統：幹掉可以幹掉的，團結幹不掉的

對於一個在進行數字化轉型的傳統行業企業，一般來說都已經經過了初期的資訊化建設，有了各種各樣的已有系統，有的是買來的，有的是自己開發的。如何在這種前提下，統一規劃和逐步實現公司的數字化平臺進而實現數字化轉型，是需要技術者重點考慮的。

對於X公司來說，已有的系統包括了自己開發的OA、買來的酷家樂設計工具、買來的管家婆ERP等等等等，我們所採用的方針的就是：幹掉可以幹掉的，團結幹不掉的。

舉個例子，像對於OA這種自己初期開發的並不完善的系統，它的作用是各個業務部門之間的資訊傳遞和協作，屬於核心業務線上化的範疇，我們採取的是逐步幹掉它，因為後面平臺中的各個新應用系統已經實現了它的功能，而且能更好地讓各個業務部門進行協作和共享。

而像對於酷家樂/三維家這種買來的設計工具，我們採取的是努力團結它，因為設計雖然我們的核心業務（比如一般企業的核心業務都是營銷、研發/生產、供應鏈），但是工具這塊不是我們的核心業務而且我們也真做不出來這種高效率的設計工具，因此我們需要努力團結它並使用它提供的開放介面和線上設計能力與我們的平臺進行整合和整合，為我們的設計師提供統一的設計能力體驗。

畫外音：業務上的遺留系統儘可能逐步幹掉，這樣才能統一資料來源。當然，前期可以採用資料同步的方式並行跑，但一定要把資料同步到新的統一資料來源中。工具上的遺留系統儘可能保持現狀，對這種工具的選型也要根據企業自身的情況來選擇，比如沒有供應鏈能力的家裝企業可能會選擇躺平，而自身有供應鏈能力的家裝企業可能會選擇酷家樂。當然，酷家樂/三維家和躺平走的模式本來就不同，選擇也應當和自己企業的發展階段和定位來進行匹配。

4、小結

本文介紹了我在X公司的技術體系和架構，以及我們使用的一些元件和實踐，都是一些high-level的介紹，沒有具體的東西。當然，還有很多不完善的地方以及需要持續演進優化的，但是它目前已經滿足了X公司的業務需要和發展要求。此外，本文所分享的內容也存在著很多個人的偏見和愚昧，因為每個人的經歷和認知都不同，我只能處在我這個認知前提下說出我想說的內容。

最後，謝謝大家的閱讀！

作者：周旭龍

出處：https://edisonchou.cnblogs.com

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連結。