小數近期爲大家推送了不少微服務方面的文章，之前的一份微服務調研報告《[微服務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
