微服務遷移前，來聽聽這6個思考和經驗

小數近期爲你們推送了很多微服務方面的文章，以前的一份微服務調研報告《[微服務2017年度報告出爐：4大客戶畫像，15%傳統企業已領跑]受到普遍關注。今天推送的這篇技術文章，與您再來深刻探討下企業爲何要尋求微服務，會遇到哪些問題，作好哪些準備。

今天，對軟件的需求變化比以往任什麼時候候都快。這就要求有一個合適的架構來實現靈活的變動。然而，考慮到Web應用的角度，靈活性每每受到阻礙。隨着時間的推移，各類意想不到的依賴關係會使架構看起來像一個大泥球（Big Ball of Mud，BBoM)。

相似BBoM的龐大單體架構顯示出的複雜性急劇增長。這須要各個團隊之間的協調努力，纔不會致使生產力下降。做爲對策，企業引入了Scrum敏捷方法來優化他們的軟件工程流程。可是，常常缺少技術自主權。

敏捷性和微服務

在敏捷軟件開發中，一個理想的架構足夠靈活，能夠處理快速調整的需求。遵循敏捷宣言的原則，最好的架構以功能需求驅動的方式出現。但架構也須要前期設計的努力，以實現預期的靈活性。因爲需求的不肯定性，嚴格的瀑布式的前期大型設計（Big Design Upfront ，BDUF)被忽略了。BDUF不適合大量連貫工做量的敏捷思想，也稱爲the batch size。

微服務方法限制了batch size，由於每個微服務只涵蓋整個應用的一部分。全部部分共同涵蓋不一樣的業務功能，例如在電商應用中顯示產品的詳細信息。重要的一點是，單一業務能力的責任轉移到一個須要跨職能一致和須要DevOps文化的團隊。

所以，微服務是一個模塊化的概念，能夠解釋技術層面和組織層面。這個想法是圍繞清晰分離的業務能力建模一個架構，每一個業務能力都是做爲一個微服務實現的。經過實施本身的架構與系統的其餘部分分離，容許創建大規模的軟件增量與小型和獨立的團隊。微服務最適宜的企業是，旨在縮短業務上線時間，但沒法應對當前架構和組織結構快速變化需求的那些企業。

向微服務遷移有許多挑戰。如下提供了從BBoM引入微服務的幾點指南。

微服務遷移的六大影響因素

向微服務的遷移能夠徹底脫離，也依賴於單體（因素1）。關鍵的決定是，目標架構的微服務是否包含本身的前端（frontend）（因素2）。在這個階段，技術和組織方面之間的相互做用已經變得明確。當涉及從巨石中分離出第一個微服務時，應該確保底層的新模型不會被舊的破壞（因素3）。運維中的遷移應該考慮風險，並採起適當的措施（因素4）。經過自動化過程來支持（因素5）。把適當的工做放在優先位置。所需的透明度經過敏捷的組織文化來創建。將敏捷轉換與微服務遷移結合起來會帶來額外的挑戰（因素6）。

1改變

人們常常認爲，徹底重寫應用程序是充滿風險的。可是這個應用程序的發佈並非以一個Big Bang的方式來完成的。相反，能夠選擇漸進的方法。可是，巨石應用和微服務一塊兒構成應用程序的「微服務 – 單體 - 混合」架構每每是不可避免的。特別是若是有競爭的壓力，新的特性必須不斷傳遞給客戶，那麼混合是惟一的解決方案。遷移是一個長期的過程，能夠持續2年以上。

爲了縮短應用程序處於混合狀態的時間，建議將遷移視爲變化的機會。在這種狀況下，改變意味着實施新的要求，並且接受現有功能的遺漏。一方面，考慮遷移的應用程序是舊的應用程序的準確副本，減小遷移工做是明智的。另外一方面，提供不適用於舊技術堆棧的新功能加強利益相關方的信任。這種遷移能夠視爲進步而並不是停滯。

2系統分解

有兩個必須考慮的決定。首先，是否經過使用現有的代碼庫或者徹底重寫功能來提取微服務。其次，定義目標架構，而且必須作出決定，微服務是自帶前端，仍是多個微服務集成在一個UI單體中。

當使用現有的代碼庫時，該代碼庫的副本就是跳板。那麼給定的部分已經表現出高度的自主性。並且，當項目範圍侷限於較少人數開發應用時，這種方法可能會取得成功。當挑戰是將多個團隊分離時，建議將微服務定義爲本身的前端。

圖1：2層微服務 VS 全堆棧微服務

這須要進一步討論如何解釋微服務的層次。關於三層架構，能夠區分兩種微服務類型。一方面是隻包含數據和應用程序層的微服務（圖1）。另外一方面還有從數據層到表現層的微服務。

圖2：UI-monolith 與 UI-fragments

當使用「2層微服務」時，在創建前端的這種多微服務時創建了一個UI單體。這帶來了將微服務整合到同一個前端的耦合團隊的風險。相比之下，提供本身的前端部分的「全棧微服務」（例如UI碎片）則爲團隊提供了更高程度的自主權（圖2）。

3模型邊界保護

做爲一個起點，建議從中等複雜度的單個上下文開始。這樣作的時候，保護即將實現這個上下文的微服務底層模型很重要。所以，應該規定一條規則，即禁止經過數據層訪問（如JDBC或直接API調用）從總體數據訪問數據。相反，數據應該從後臺異步傳輸到後臺的微服務，同時還要在新舊模式之間進行轉換。這能夠看做兩個數據存儲的同步，並符合構建防腐層（ACL）的思想，這是一個域驅動設計（DDD）的概念。在這種狀況下，ACL能夠做爲微服務和巨石的模型完整性保護器（圖3）。

圖3：ACL做爲微服務和單體之間的邊界

4風險監測

任何遷移都有風險。特別是在進行徹底重寫時，若是新應用程序與現有應用程序相比獲得相同的結果，則應使用與業務相關的度量標準（如營業額）進行衡量。而後，經過逐漸將新應用交付給愈來愈多的客戶，控制經濟風險。在這一點上，應該考慮諸如Canary Releasing的部署策略。

另外，建議在生產環境中測試微服務，而後再將其推廣給客戶。這能夠經過向微服務提供請求並徹底觀察他們的行爲Shadow Traffic來實現。性能問題能夠在不影響應用程序的狀況下展開，由於各自的響應被省略。這種作法是由兩位專家和文獻描述的。

其餘措施也能夠支持下降雲服務遷移過程當中的風險。使用諸如特性切換之類的機制在舊的和新的實現之間切換。它們提供了靈活性，僅經過更改配置來控制這一點，而無需從新部署整個應用程序。

5自動化和測試

爲了減小TTM（上市時間），做爲微服務的部署流水線，建議將價值流建模和自動化。在這裏，要考慮從代碼提交到部署構建的每一步。這確保部署能夠常常進行。此外，這從一開始就支持高度的測試覆蓋，由於測試也是該流水線的一部分。

在考慮自動化測試時，專家會參考所謂的自動化測試金字塔。測試金字塔由三個測試層組成：單元，服務和UI測試。每層測試的數量減小，致使金字塔形狀--許多單元測試和少許UI測試。爲了確保多個微服務如預期的那樣相互整合，依靠UI測試是合理的。但UI測試對於開發和維護來講是脆弱和昂貴的。這就是爲何在沒有UI的狀況下單獨進行測試很是重要：使用模擬對象自主地測試微服務。藉助模擬對象，能夠模擬與其餘微服務或巨石應用的交互。相應的測試被稱爲，自動測試金字塔內的服務級別測試。

6敏捷轉型

引入敏捷方法並當即遷移到微服務是巨大的變化。所以，建議將其分紅幾個步驟，並尋求逐漸改變。不然動機和定向障礙的風險過高。經過引入Scrum這樣的敏捷方法，理想的微服務出現，是隨着時間的推移爭取團隊的自主性。

儘管Scrum主要是在一個跨職能和以產品爲中心的團隊中解決軟件開發過程，大規模的組織也須要採用。Scrum沒有提供解決多個敏捷團隊協調的解決方案。還有一些堅決的觀點認爲，對於大型項目來講，應該避免使用靈活的方法來分割產品。隨着時間的推移，出現了不一樣的Scrum和敏捷方法擴展方法。例如，LeSS（大規模Scrum），Nexus和SAFe（縮放敏捷框架）是根據其市場份額爲大型組織提供敏捷性的相關方法。

在更大的組織環境中創建敏捷方法時，建議先從一個團隊開始，而後再增長愈來愈多的團隊。一樣在LeSS中，這被描述爲耗時，但倒是以功能爲中心的團隊，同時打破功能孤島的安全方式。

透明度

此外，建議記錄產生的非功能性工做，例如在積壓工做中實施ACL，併合理安排其餘要求。在SAFe中，引入了能夠表明上述技術和機制的實施以及遷移工做的推進者的故事。它們確保了透明度，展示了業務與IT之間潛在的相互依賴關係。所以，應根據2位專家的建議，與企業和技術負責人進行優先排序。

圖4：敏捷和微服務之路

總結

微服務包含組織層面和技術方面。這就是爲何引入微服務涉及兩種狀況下的措施。若是沒有單體考慮，微服務的好處是脆弱的。從純粹的技術角度來看，微服務可使用瀑布式軟件工程方法來實現。可是，爲了充分發揮每一個微服務的自主性，它們被嵌入到敏捷文化中。

特別是，擁有多個團隊的組織能夠從微服務的非技術方面獲益。從數據層向前端分解一個系統，將團隊分離開來。所以，若是多個團隊使用一個前端開發應用程序，那麼團隊邊界在架構中反映最好。這些團隊能夠自主地加速應用程序的部分。在單體應用程序和分層的團隊中，這是更困難的。在這裏，複雜的依賴須要協調跨越團隊邊界的活動。所以TTM降低。

因爲敏捷團隊由開發人員和非技術人員組成，所以IT和業務須要攜手合做。微服務的出現是因爲敏捷團隊爭取自主權。當團隊決定轉向微服務時，遷移自己沒有任何價值，能夠向客戶交付新功能。儘管如此，微服務遷移工做仍須要優先考慮。這須要透明度。只有不斷提升透明度，敏捷性和微服務才能彼此加速。不然，長期不會下降TTM的風險很高。

爲了不在引入微服務時構建將來的傳統軟件，創建敏捷思惟和不斷從新思考解決方案很重要。

原文連接：

6 Things to Consider for Microservice Migration

https://www.inovex.de/blog/mi...