小數(shù)近期為大家推送了不少微服務(wù)方面的文章，之前的一份微服務(wù)調(diào)研報告《[微服務(wù)2017年度報告出爐：4大客戶畫像，15%傳統(tǒng)企業(yè)已領(lǐng)跑]受到廣泛關(guān)注。今天推送的這篇技術(shù)文章，與您再來深入探討下企業(yè)為什么要尋求微服務(wù)，會遇到哪些問題，做好哪些準備。
今天，對軟件的需求變化比以往任何時候都快。這就要求有一個合適的架構(gòu)來實現(xiàn)靈活的變更。然而，考慮到Web應(yīng)用的角度，靈活性往往受到阻礙。隨著時間的推移，各種意想不到的依賴關(guān)系會使架構(gòu)看起來像一個大泥球（Big Ball of Mud，BBoM)。
類似BBoM的龐大單體架構(gòu)顯示出的復(fù)雜性急劇增加。這需要各個團隊之間的協(xié)調(diào)努力，才不會導(dǎo)致生產(chǎn)力降低。作為對策，企業(yè)引入了Scrum敏捷方法來優(yōu)化他們的軟件工程流程。但是，經(jīng)常缺乏技術(shù)自主權(quán)。
敏捷性和微服務(wù)
在敏捷軟件開發(fā)中，一個理想的架構(gòu)足夠靈活，可以處理快速調(diào)整的需求。遵循敏捷宣言的原則，最好的架構(gòu)以功能需求驅(qū)動的方式出現(xiàn)。但架構(gòu)也需要前期設(shè)計的努力，以實現(xiàn)預(yù)期的靈活性。由于需求的不確定性，嚴格的瀑布式的前期大型設(shè)計（Big Design Upfront ，BDUF)被忽略了。BDUF不適合大量連貫工作量的敏捷思想，也稱為the batch size。
微服務(wù)方法限制了batch size，因為每一個微服務(wù)只涵蓋整個應(yīng)用的一部分。所有部分共同涵蓋不同的業(yè)務(wù)功能，例如在電商應(yīng)用中顯示產(chǎn)品的詳細信息。重要的一點是，單一業(yè)務(wù)能力的責(zé)任轉(zhuǎn)移到一個需要跨職能一致和需要DevOps文化的團隊。
因此，微服務(wù)是一個模塊化的概念，可以解釋技術(shù)層面和組織層面。這個想法是圍繞清晰分離的業(yè)務(wù)能力建模一個架構(gòu)，每個業(yè)務(wù)能力都是作為一個微服務(wù)實現(xiàn)的。通過實施自己的架構(gòu)與系統(tǒng)的其他部分分離，允許建立大規(guī)模的軟件增量與小型和獨立的團隊。微服務(wù)最適宜的企業(yè)是，旨在縮短業(yè)務(wù)上線時間，但無法應(yīng)對當前架構(gòu)和組織結(jié)構(gòu)快速變化需求的那些企業(yè)。
向微服務(wù)遷移有許多挑戰(zhàn)。以下提供了從BBoM引入微服務(wù)的幾點指南。
微服務(wù)遷移的六大影響因素
向微服務(wù)的遷移可以完全脫離，也依賴于單體（因素1）。關(guān)鍵的決定是，目標架構(gòu)的微服務(wù)是否包含自己的前端（frontend）（因素2）。在這個階段，技術(shù)和組織方面之間的相互作用已經(jīng)變得明確。當涉及從巨石中分離出第一個微服務(wù)時，應(yīng)該確保底層的新模型不會被舊的破壞（因素3）。運維中的遷移應(yīng)該考慮風(fēng)險，并采取適當?shù)拇胧ㄒ蛩?）。通過自動化過程來支持（因素5）。把適當?shù)墓ぷ鞣旁趦?yōu)先位置。所需的透明度通過敏捷的組織文化來建立。將敏捷轉(zhuǎn)換與微服務(wù)遷移結(jié)合起來會帶來額外的挑戰(zhàn)（因素6）。
1改變
人們經(jīng)常認為，完全重寫應(yīng)用程序是充滿風(fēng)險的。但是這個應(yīng)用程序的發(fā)布并不是以一個Big Bang的方式來完成的。相反，可以選擇漸進的方法。但是，巨石應(yīng)用和微服務(wù)一起構(gòu)成應(yīng)用程序的“微服務(wù) – 單體 - 混合”架構(gòu)往往是不可避免的。特別是如果有競爭的壓力，新的特性必須不斷傳遞給客戶，那么混合是唯一的解決方案。遷移是一個長期的過程，可以持續(xù)2年以上。
為了縮短應(yīng)用程序處于混合狀態(tài)的時間，建議將遷移視為變化的機會。在這種情況下，改變意味著實施新的要求，而且接受現(xiàn)有功能的遺漏。一方面，考慮遷移的應(yīng)用程序是舊的應(yīng)用程序的準確副本，減少遷移工作是明智的。另一方面，提供不適用于舊技術(shù)堆棧的新功能增強利益相關(guān)方的信任。這種遷移可以視為進步而并非停滯。
2系統(tǒng)分解
有兩個必須考慮的決定。首先，是否通過使用現(xiàn)有的代碼庫或者完全重寫功能來提取微服務(wù)。其次，定義目標架構(gòu)，并且必須做出決定，微服務(wù)是自帶前端，還是多個微服務(wù)集成在一個UI單體中。
當使用現(xiàn)有的代碼庫時，該代碼庫的副本就是跳板。那么給定的部分已經(jīng)表現(xiàn)出高度的自主性。而且，當項目范圍局限于較少人數(shù)開發(fā)應(yīng)用時，這種方法可能會取得成功。當挑戰(zhàn)是將多個團隊分離時，建議將微服務(wù)定義為自己的前端。
圖1：2層微服務(wù) VS 全堆棧微服務(wù)
這需要進一步討論如何解釋微服務(wù)的層次。關(guān)于三層架構(gòu)，可以區(qū)分兩種微服務(wù)類型。一方面是只包含數(shù)據(jù)和應(yīng)用程序?qū)拥奈⒎?wù)（圖1）。另一方面還有從數(shù)據(jù)層到表現(xiàn)層的微服務(wù)。
圖2：UI-monolith 與 UI-fragments
當使用“2層微服務(wù)”時，在建立前端的這種多微服務(wù)時建立了一個UI單體。這帶來了將微服務(wù)整合到同一個前端的耦合團隊的風(fēng)險。相比之下，提供自己的前端部分的“全棧微服務(wù)”（例如UI碎片）則為團隊提供了更高程度的自主權(quán)（圖2）。
3模型邊界保護
作為一個起點，建議從中等復(fù)雜度的單個上下文開始。這樣做的時候，保護即將實現(xiàn)這個上下文的微服務(wù)底層模型很重要。因此，應(yīng)該規(guī)定一條規(guī)則，即禁止通過數(shù)據(jù)層訪問（如JDBC或直接API調(diào)用）從整體數(shù)據(jù)訪問數(shù)據(jù)。相反，數(shù)據(jù)應(yīng)該從后臺異步傳輸?shù)胶笈_的微服務(wù)，同時還要在新舊模式之間進行轉(zhuǎn)換。這可以看作兩個數(shù)據(jù)存儲的同步，并符合構(gòu)建防腐層（ACL）的思想，這是一個域驅(qū)動設(shè)計（DDD）的概念。在這種情況下，ACL可以作為微服務(wù)和巨石的模型完整性保護器（圖3）。
圖3：ACL作為微服務(wù)和單體之間的邊界
4風(fēng)險監(jiān)測
任何遷移都有風(fēng)險。特別是在進行完全重寫時，如果新應(yīng)用程序與現(xiàn)有應(yīng)用程序相比得到相同的結(jié)果，則應(yīng)使用與業(yè)務(wù)相關(guān)的度量標準（如營業(yè)額）進行衡量。然后，通過逐漸將新應(yīng)用交付給越來越多的客戶，控制經(jīng)濟風(fēng)險。在這一點上，應(yīng)該考慮諸如Canary Releasing的部署策略。
另外，建議在生產(chǎn)環(huán)境中測試微服務(wù)，然后再將其推廣給客戶。這可以通過向微服務(wù)提供請求并完全觀察他們的行為Shadow Traffic來實現(xiàn)。性能問題可以在不影響應(yīng)用程序的情況下展開，因為各自的響應(yīng)被省略。這種做法是由兩位專家和文獻描述的。
其他措施也可以支持降低云服務(wù)遷移過程中的風(fēng)險。使用諸如特性切換之類的機制在舊的和新的實現(xiàn)之間切換。它們提供了靈活性，僅通過更改配置來控制這一點，而無需重新部署整個應(yīng)用程序。
5自動化和測試
為了減少TTM（上市時間），作為微服務(wù)的部署流水線，建議將價值流建模和自動化。在這里，要考慮從代碼提交到部署構(gòu)建的每一步。這確保部署可以經(jīng)常進行。此外，這從一開始就支持高度的測試覆蓋，因為測試也是該流水線的一部分。
在考慮自動化測試時，專家會參考所謂的自動化測試金字塔。測試金字塔由三個測試層組成：單元，服務(wù)和UI測試。每層測試的數(shù)量減少，導(dǎo)致金字塔形狀--許多單元測試和少量UI測試。為了確保多個微服務(wù)如預(yù)期的那樣相互整合，依靠UI測試是合理的。但UI測試對于開發(fā)和維護來說是脆弱和昂貴的。這就是為什么在沒有UI的情況下單獨進行測試非常重要：使用模擬對象自主地測試微服務(wù)。借助模擬對象，可以模擬與其他微服務(wù)或巨石應(yīng)用的交互。相應(yīng)的測試被稱為，自動測試金字塔內(nèi)的服務(wù)級別測試。
6敏捷轉(zhuǎn)型
引入敏捷方法并立即遷移到微服務(wù)是巨大的變化。因此，建議將其分成幾個步驟，并尋求逐漸改變。否則動機和定向障礙的風(fēng)險太高。通過引入Scrum這樣的敏捷方法，理想的微服務(wù)出現(xiàn)，是隨著時間的推移爭取團隊的自主性。
盡管Scrum主要是在一個跨職能和以產(chǎn)品為中心的團隊中解決軟件開發(fā)過程，大規(guī)模的組織也需要采用。Scrum沒有提供解決多個敏捷團隊協(xié)調(diào)的解決方案。還有一些堅定的觀點認為，對于大型項目來說，應(yīng)該避免使用靈活的方法來分割產(chǎn)品。隨著時間的推移，出現(xiàn)了不同的Scrum和敏捷方法擴展方法。例如，LeSS（大規(guī)模Scrum），Nexus和SAFe（縮放敏捷框架）是根據(jù)其市場份額為大型組織提供敏捷性的相關(guān)方法。
在更大的組織環(huán)境中建立敏捷方法時，建議先從一個團隊開始，然后再增加越來越多的團隊。同樣在LeSS中，這被描述為耗時，但卻是以功能為中心的團隊，同時打破功能孤島的安全方式。
透明度
此外，建議記錄產(chǎn)生的非功能性工作，例如在積壓工作中實施ACL，并合理安排其他要求。在SAFe中，引入了可以代表上述技術(shù)和機制的實施以及遷移工作的推動者的故事。它們確保了透明度，展現(xiàn)了業(yè)務(wù)與IT之間潛在的相互依賴關(guān)系。因此，應(yīng)根據(jù)2位專家的建議，與企業(yè)和技術(shù)負責(zé)人進行優(yōu)先排序。
圖4：敏捷和微服務(wù)之路
總結(jié)
微服務(wù)包含組織層面和技術(shù)方面。這就是為什么引入微服務(wù)涉及兩種情況下的措施。如果沒有單體考慮，微服務(wù)的好處是脆弱的。從純粹的技術(shù)角度來看，微服務(wù)可以使用瀑布式軟件工程方法來實現(xiàn)。但是，為了充分發(fā)揮每個微服務(wù)的自主性，它們被嵌入到敏捷文化中。
特別是，擁有多個團隊的組織可以從微服務(wù)的非技術(shù)方面獲益。從數(shù)據(jù)層向前端分解一個系統(tǒng)，將團隊分離開來。因此，如果多個團隊使用一個前端開發(fā)應(yīng)用程序，那么團隊邊界在架構(gòu)中反映最好。這些團隊可以自主地加速應(yīng)用程序的部分。在單體應(yīng)用程序和分層的團隊中，這是更困難的。在這里，復(fù)雜的依賴需要協(xié)調(diào)跨越團隊邊界的活動。因此TTM下降。
由于敏捷團隊由開發(fā)人員和非技術(shù)人員組成，因此IT和業(yè)務(wù)需要攜手合作。微服務(wù)的出現(xiàn)是由于敏捷團隊爭取自主權(quán)。當團隊決定轉(zhuǎn)向微服務(wù)時，遷移本身沒有任何價值，可以向客戶交付新功能。盡管如此，微服務(wù)遷移工作仍需要優(yōu)先考慮。這需要透明度。只有不斷提高透明度，敏捷性和微服務(wù)才能彼此加速。否則，長期不會降低TTM的風(fēng)險很高。
為了避免在引入微服務(wù)時構(gòu)建未來的傳統(tǒng)軟件，建立敏捷思維和不斷重新思考解決方案很重要。
原文鏈接：
6 Things to Consider for Microservice Migration
