【編者按】本文作者Kevin Dunne是QASymphony公司戰略和業務開發的副總裁，曾在Deloitte負責管理大型政府和五百強在定制軟件開發方面的測試工作。本文中，作者通過DevOps Microservices的介紹，進一步分析其優缺點和適用性，并在解決其復雜性方面為大家提供多種思路，由 OneAPM工程師翻譯。
以下為譯文
當下，市面上存在各種可集成到開發流程中的“最佳工具”，從而只要適當的編碼就可以通過微服務來支撐業務。但萬事過猶不及，以下向大家介紹如何在適當的時機使用微服務。
目前，微服務正風靡一時：使用微小的應用集成應用程序可以非常方便地進行更新。微服務像膠水，在DevOps自動流程中將處理和系統合并。采用微服務意味著更快更自動化的周期，更好地實現持續交付，同時有助于提高DevOps流程和部署的可見性。
對于開發和測試工作者來說，他們往往喜歡采用更適合某種工作的“最佳工具”，微服務允許開發者在DevOps流水線中使用各種不同的開源和商業工具，更好地滿足需求。另一方面，也存在一些工具會內置集成這些工具，但這些集成并不能完全適應于用戶需求。如果要求供應商根據需求重新定制集成工具則會出現成本過高，同時可能無法在規定時間內實現。
所以，開發團隊不妨利用微服務靈活地構建自己的工具包，并可以整合所有用于提高開發過程可見性的產品。與此同時，相對于傳統APIs，REST API能非常容易地適用于各種開發需求；無需任何關于該產品的專業知識，開發者便可以輕松編寫微服務。以上只是眾多微服務方式強大優勢中的一部分。
不過，在享受這些優勢時，用戶同樣需要注意以下幾點：
1. 難以駕馭。微服務依賴于提供者的API，當這些API改變時，服務將會中斷。然后必須從頭開始重建服務。所以需要你騰出手來，開始這項耗時的工作：編寫并完善代碼。在成百上千微服務的環境下，開發者們會花費著大量時間來更新DevOps流水線上的那些惱火的小應用，而沒時間開發新的用戶功能。所以，這會導致成本和時間的增加。
2. 草率處理。在為團隊寫微服務時，任何人都想盡可能快地交差，所以會跳過一些步驟導致微服務脆弱不堪。鑒于所編寫的微服務會面對成百上千的用戶，因此它必須是堅強穩固的。通過微服務整合內部方法可能更容易遭到破壞。一旦某個服務出現故障，不可避免地會給其他集成點造成多米諾效應，導致開發過程的中斷。
為了解決以上問題，不妨采用以下有效措施。首先，確保你已經采取了更實惠的方式。是否開發微服務的整合策略比提供的服務更為便宜（需考慮員工時間）。如果成本不是主要的考慮因素，那么開發一個定制的DevOps工具包的好處遠遠大于復雜性問題，包括服務中斷的宕機風險。相對于供應商不夠完善的集成來說，定制集成是否有更明確的好處？在選擇微服務之前，必須結合商業利益及諸多方面進行細節分析。
以下方法可以進一步降低微服務的復雜性：
混合型：在大多數情況下，很多企業覺得供應商集成和微服務結合往往是更好的選擇。
外包：對于關鍵業務的應用，讓外包開發公司幫助你處理微服務部分，這不失為一種好主意。這種方式既可以降低你的風險，還能解放你的開發者，讓他們專注于構建產品而不用糾結于管理集成。
工具和語言：選擇與REST API有較好適用性的語言來編寫微服務，比如Python和Ruby。同時，密切留意可以幫助公司工作的內部工具，如Zapier或Tasktop。當公司擴大微服務和容器的使用范圍，進一步優化其DevOps操作時，我們期待這些自動選項會不斷增加。
原文鏈接： How to Handle DevOps Microservices
京公網安備 11010502049343號