摘要：坎貝爾說我們已經看到，隨著團隊采用微服務，從提交到制作的周期時間顯著縮短。轉向微服務代表著一場大變革，各個組織需要做好應對這種重大轉變的準備。表示，企業(yè)還應考慮根據業(yè)務優(yōu)先級為每個微服務的性能和可靠性定義服務水平協(xié)議。

如今新應用程序的開發(fā)都與交付速度有關。向敏捷環(huán)境的大規(guī)模轉移已經持續(xù)了數年，這促使人們有一種輕松快速地部署軟件的意識。

微服務是面向服務的體系結構（SOA）的一種變體，它將應用程序構建為松散耦合服務的集合。將應用程序拆分為更小服務的好處包括：改進了模塊化，使應用程序更易于開發(fā)和測試。

“微服務增強了團隊授權，減少了耦合，使各個團隊能更快地進行創(chuàng)新，減少跨團隊之間的溝通，并且有權自己做出有關架構、語言和框架的決策，”Verizon媒體集團（Verizon Media Group）工程、體育及媒體制作工程副總裁坎貝爾（EJ Campbell）說道，該集團是擁有50個在線品牌的通信公司的子公司。

坎貝爾說：“我們已經看到，隨著團隊采用微服務，從提交到制作的周期時間顯著縮短。” “許多團隊每天多次部署微服務，無需任何人工干預，依靠測試、代碼審查和復雜的CI／CD（持續(xù)集成／持續(xù)交付）管道來確保變更內容的安全交付。”

該公司的“Yahoo Daily Fantasy”產品含有多個微服務，包括核心游戲服務、體育數據服務、錢包服務和一些支持內部服務?！斑@些服務中的每一個都有自己的持續(xù)部署管道、獨立的數據存儲以及負責其開發(fā)和運營的各自團隊，”坎貝爾說。

使用微服務時，各個組織可能會遇到許多挑戰(zhàn)。這些挑戰(zhàn)包括確定多個服務之間的正確邊界，克服微服務環(huán)境中團隊之間共享代碼的困難，以及克服變更管理的復雜性，因為各團隊都是獨立發(fā)布代碼。

轉向微服務代表著一場大變革，各個組織需要做好應對這種重大轉變的準備。

“向微服務的演變就像是從馬到自行車，或從自行車到汽車的過程，”Solutions By Design II （SBD）公司項目副經理Jay Bercher說道，這是一家管理咨詢和技術服務公司，與聯(lián)邦機構合作，協(xié)助其轉向基于微服務的IT工作方式。

“當我們經歷演變的多個階段時，我們會發(fā)現(xiàn)有更多的東西在變化，”Bercher說。“每個變化的東西都需要一定級別的維護，對這么多方面的支持和監(jiān)督不僅使解決方案更加復雜，而且還增加了相關成本。因此，我們必須仔細審查我們的決定，以確保這些決定不僅是最佳的技術決策，而且還具有成本效益?！?/p>

另一個挑戰(zhàn)是安全性?！拔覀儽仨毚_定是否要在整個應用程序中實施單一驗證解決方案，或者我們是否要對每個微服務都設置其自己的驗證流程，”Bercher說?！斑@是一個必須根據具體情況做出的決定，并且是每個項目團隊需要自己做出的決定?！?/p>

以下是一些建議的最佳做法，以應對挑戰(zhàn)并在微服務環(huán)境中順利發(fā)展。

采用領域驅動設計

Bercher說，創(chuàng)建微服務是為了使服務松散耦合，并應用單一責任原則。

“盡管有各種開發(fā)方式和方法，但領域驅動設計和微服務似乎是完美組合，”Bercher說。 SBD公司的團隊使用領域驅動設計，這是一種構建應用程序的主題方法，可創(chuàng)建一種高效的開發(fā)模式，消除大多數團隊的相互依賴性。

“在我們的工作中，領域與微服務的相關性基本上是一對一的，”Bercher說?！耙虼耍總€開發(fā)團隊都負責一個領域，同時也負責開發(fā)相應的微服務。這就建立了明確的責任劃分，從而限制了并行開發(fā)工作中可能出現(xiàn)的冗余。”

建立代碼庫指南

坎貝爾說，在微服務環(huán)境下，團隊之間共享代碼要困難得多。

“不像在一個整體架構中，公共代碼只是一個方法調用，而微服務架構的通用性必須分解到獨立的服務中，或者代碼必須打包到一個共享庫中，”坎貝爾說。

使用這些庫通常很慢，并且進行更改需要在庫所有者和多個服務之間進行協(xié)調。“因此，對于公共庫和上線產品的要求，各個組織應采用一套強有力的指導方針，這非常重要，”坎貝爾說。

不要在微服務之間共享數據庫

“在構建我們的解耦合服務時，我們允許我們的開發(fā)團隊構建自己的數據庫，為我們的（后端系統(tǒng)）提供數據，這可限制對其他開發(fā)團隊的依賴性，”Bercher說。

“我們的開發(fā)團隊將他們書寫的內容推送到后端，供其他人使用，然后我們的數據團隊會管理這些信息，”Bercher說?！斑@延續(xù)了即插即用的概念。如果您需要更換某一服務，只需將其取出并插入新服務即可。這就像更換燈泡，只是稍微復雜一點?！?/p>

由于微服務在設計上是模塊化的，因此開發(fā)過程主要是即插即用，從而可以非常輕松地解決可能出現(xiàn)的任何問題。

“因為代碼不會在整個平臺上傳播，我們可以快速將問題隔離到一個特定的源，然后在微服務中對其跟蹤，”Bercher說?！巴ㄟ^允許對每個微服務進行零碎的更新和升級，可以輕松更新應用程序。你能想象一次升級一個系統(tǒng)而不進行大規(guī)模替換嗎？僅這一概念就徹底改變了系統(tǒng)開發(fā)?！?/p>

SBD公司在美國各地設有開發(fā)團隊，可以增強微服務的優(yōu)勢。位于南卡羅來納州查爾斯頓的團隊成員具有更高的開發(fā)獨立性，因為他們正在開發(fā)自己的微服務，并可將其加入解決方案中。

解決安全問題

與IT相關的任何其他事情一樣，微服務也有自己的安全問題。

企業(yè)應該在軟件開發(fā)生命周期的早期就要頻繁地查找已知的漏洞，電子商務、支付和營銷服務提供商數字湖公司（Digital River）的首席信息官瑞恩?道格拉斯（Ryan Douglas）說。

道格拉斯說：“對于我們在快節(jié)奏環(huán)境中工作的任何IT團隊來說，一個重要信條是識別和修復本地解決方案以及第三方軟件的漏洞?！薄斑@對維護安全至關重要。對軟件生態(tài)系統(tǒng)采取全局方法，了解它如何協(xié)同工作以及潛在問題區(qū)域所在，這是至關重要的?！?/p>

道格拉斯說，使用微服務時，軟件補丁部署更容易測試?！岸疫@不僅適用于自己開發(fā)的代碼，”他說?！癐T工程師可以在自己開發(fā)軟件的同時測試第三方軟件的漏洞。一旦發(fā)現(xiàn)漏洞，可以比以前的單一代碼結構更快地部署修復程序。”

避免出現(xiàn)復雜情況

DXC Technology公司是在CSC公司和惠普企業(yè)部門合并后成立的一家IT服務提供商，該公司的應用服務首席技術官JP Morgenthal說，復雜情況在大型微服務部署中很容易發(fā)生。

“如果組織機構沒有謹慎地確保某一系統(tǒng)架構來推動微服務的使用，甚至可能存在遞歸數據路徑，Morgenthal說?！霸谑褂锚毩⒌目缏毮軋F隊和服務存儲庫之間，可能會出現(xiàn)依賴關系，從而導致系統(tǒng)使微服務原則失效，”他說。

應該能夠更改或刪除單個微服務，而不會對整個系統(tǒng)產生重大影響。Morgenthal表示，最佳做法是使用企業(yè)架構來驗證微服務設計。

考慮從頭開始構建應用程序

房地產服務提供商Carrington Mortgage Holdings推出的直接面向消費者的抵押貸款平臺Vylla．com，該平臺最近將其技術架構轉移到微服務。

“當我們決定遷移到微服務時，我們遇到的挑戰(zhàn)之一是，是否要逐個拆分應用程序或進行完全重寫，”Carrington Mortgage公司首席技術官約翰?尼古拉斯（John Nicholas）說。

“由于一些預先設定的業(yè)務需求，我們需要在很短的時間內提供新功能，”尼古拉斯說。 “起初，我們試圖通過一些成功的結果整合到整體架構中。然而，我們也知道，將應用程序拆分會比重寫我們現(xiàn)有的大部分功能更加困難。”

考慮到這一點，開發(fā)團隊決定最好的前進方向是從頭開始構建新的應用程序?！斑@是一項艱巨的任務，需要我們所有團隊成員付出巨大努力，但自從做出這種轉變后，在短時間內就證明這是值得的，”尼古拉斯說。

尼古拉斯表示，由于成功部署微服務需要大量的技術投資，因此必須有一個明確定義的商業(yè)案例，來概述新技術如何提高性能或提高運營效率，這是很重要的。

“這里的關鍵是找到合適的人才，”尼古拉斯說。“找到有經驗的工程師能輕松完成這一工作并不容易。我們已經能夠建立一個強大的工程團隊，了解正確的架構，并且有一支強大的質量保證團隊，圍繞應用程序構建自動化測試?！?/p>

進行擴展時，需衡量其性能

通過添加服務器，可對整體應用程序進行全面擴展以滿足需求的飆升，SpotCues公司的聯(lián)合創(chuàng)始人Praveen Kanyadi表示，該公司利用人工智能提供生產力軟件。

“對于微服務來說，模塊化架構只允許對系統(tǒng)的某些部分進行擴展，”Kanyadi說?！叭欢⒎招枰环N非常不同的擴展方法，因為典型的微服務架構部署可能包含在不同服務器上運行的多個組件以及虛擬化協(xié)同工作?！?/p>

在識別哪些單個組件升級方面，這就增加了挑戰(zhàn)?！斑@是衡量性能變得至關重要的地方，而像應用程序交付控制器等工具可以幫助測量和檢測性能問題，”Kanyadi說。

Kanyadi表示，企業(yè)還應考慮根據業(yè)務優(yōu)先級為每個微服務的性能和可靠性定義服務水平協(xié)議（SLA）。

專注于變革管理

企業(yè)需要更新變革管理和變更控制流程以及支持文檔，以便從整體架構向微服務架構的轉變中受益。

“更快的開發(fā)過程很好，但不要因為忽略變更控制和其他重要的治理流程而丟掉微服務的好處，”Avant Communications公司的首席云計算官羅恩?海曼（Ron Hayman）說道，該公司為IT渠道銷售市場提供云服務。

“確保您將變更控制和審批流程與您的敏捷開發(fā)生命周期相匹配，”海曼說。