目前每個企業都想做微服務，但如何做好微服務？微服務改造過程中有哪些必須重視的問題？博雲通過自己的實踐，總結了一些經驗之談。日前InfoQ對博雲高階解決方案架構師趙安全就此話題進行了專訪，以茲各位對微服務感興趣的朋友們。

微服務是一種軟體架構風格，以專注於單一責任與功能的小型功能區塊 (Small Building Blocks) 為基礎，利用模組化的方式組合出複雜的大型應用程式，各功能區塊使用與語言無關 (Language-Independent/Language agnostic) 的 API 集相互通訊。在去年，我們更多的還只是聽到大家都在談論微服務這個概念，但是在今年，就已經有很多微服務落地專案了，並且可以越來越多的企業在向微服務架構轉型。企業到底要不要轉向微服務，又該怎麼向微服務轉型？關於這些問題，我們採訪了BoCloud博雲高階解決方案架構師趙安全，來看看企業在微服務轉型中應該注意什麼。

微服務面面觀

不得不說，現在“微服務”在各大部落格、技術訂閱號和技術會議中出現的頻度越來越高。然而，像其他新技術一樣，對於微服務很多人都是“一解釋就懂，一問就不知”。那麼我們到底應該如何理解微服務呢？

在趙安全看來，對於技術的理解主要看大家有什麼樣的需求。對於微服務而言，它可以解決企業的哪些需求呢？

• 首先是服務複用。企業內部會有很多應用，每個應用都會有一些通用的東西，比如常見的通知、授權等，還有些內部的特殊服務，如何把這些服務通用起來，就是服務複用；
• 其次是對分散式高可用、高彈性和高效能有需求；
• 還有一個方面跟DevOps理念相關，就是要支援快速迭代。如果應用架構不改，是無法在DevOps實踐中實現快速迭代的。

很多人會問微服務和SOA的區別，其實從核心需求來講，微服務架構和SOA區別並不是特別大。但微服務有個比較重要的點，就是可以獨立部署，獨立發展，這是跟SOA最主要的區別。服務可以獨立部署就更容易快速迭代，這也是微服務要解決的一個問題。

微服務在滿足我們諸多需求的同時，也帶來了極大的挑戰：

• 微服務把一個服務拆分成了很多個，維護的物件就變多了；
• 維護物件變多之後，如果一個任務出現問題，將很難定位出現問題的節點；
• 微服務化開發需要熟悉微服務開發框架、中介軟體，需要考慮失效、容錯等策略，給開發也帶來了新的挑戰；
• 微服務如果拆分不好，會大量引入分散式事務，處理起來會比較麻煩；
• 對測試的挑戰就更大了，微服務化之後，單一模組無法獨立完成業務功能，而整合測試會在非常靠後的時候才能做，就要求需要大量引入API自動化測試等測試方法。

我適合向微服務轉型嗎

眼看別人都在向微服務架構轉型，那企業自己要不要轉向微服務呢？

趙安全認為，是否要做微服務，主要考慮如下幾個方面：

• 從需求角度考慮，有網際網路化的彈性、快速迭代、高併發、高可用的需求。
• 企業業務複雜度高，需要長期演進。
• 企業有業務複用的需求，希望能減少重複造輪子，降低成本。

從行業角度來說，目前來看，一些大型的國企和金融機構都在向微服務轉型，為什麼是大中型的企業呢？因為他們本身的應用專案不是一次可以做完的，而是需要基於一個產品做長期的持續演進開發的過程，業務複用的需求也很迫切。如果是一個固化從來不升級的產品，就沒有做微服務化的意義。

企業落地微服務的難點

BoCloud博雲作為企業級雲端計算解決方案提供商，幫助很多企業完成了微服務架構轉型，從這些案例中趙安全總結出了微服務落地的幾個難點。

首先，一個很大的難點是要捋清需求，判斷自己是否要做微服務。現在一個普遍的現象是，大家沒想清楚為什麼要做微服務就開始做了。如果只是做了服務拆分而並沒有複用的需求，或者沒有高併發、彈性甚至是分散式的需求，做微服務的意義也不大。

其次，微服務設計上有難度。大家不知道怎麼設計，以為就是把服務簡單拆一下就可以了，這明顯是不靠譜的。微服務的拆分設計，一定是要花很多時間的。微服務產品前邊的設計工一定要做詳細，把API等因素全都想清楚了再開始做。

第三，流程上也有一些變化。新需求來了怎麼辦？是在原來的微服務裡重新修改，還是做一個新的微服務？這是需要從中間去考慮的，而不是像原來一樣，有需求過來就開始改。

第四，在技術方面，其實掌握一套框架還是需要時間的。Spring Cloud框架並不是特別簡單，需要理解它的流程和方法，開發人員的開發習慣或方式可能也需要發生一些變化。

企業怎樣做微服務？

企業到底應該如何來做微服務呢？趙安全介紹到，整體來講，做微服務主要要考慮到微服務的拆分、架構選型和架構演進。

微服務拆分原則

在微服務拆分中，核心的需求在於拆開的微服務之間的聯絡越少越好，雖然我們強調複用，但是聯絡越少越好，資料互動也是越少越好。因為微服務之間的資料一致性非常難處理，如果一致性方面的問題很少，整體做起來就比較簡單了。

微服務架構選型

微服務架構的選型也是一個讓大家比較糾結的事情。趙安全說，從過去的經驗來看，選擇開源技術時，社群的活躍度是非常重要的參考。但博雲在做選型的時候，有一些元件並沒有按照所謂的社群活躍度來選，就是因為還有第二個選型的原則：一定要滿足需求，這是要重點考慮的。第三點原則是掌控能力。假設一個框架是用C語言寫的，整個團隊沒有懂C語言的人，這樣肯定不行。因此總結下來就是，微服務架構選型需要考慮：社群活躍度、需求滿足度、掌控能力，這三方面。

拿BoCloud博雲的微服務平臺BeyondMS來說，BeyondMS的框架有兩套：

• 一套是現在比較流行的Spring Cloud框架；

基於Spring Cloud的框架，博雲在Spring Cloud的基礎上做了一些變化：

1. 因為Zuul的效能問題，BeyondMS的API閘道器從Zuul改成了更高效能的Kong。
2. 因為Spring Cloud原生的配置中心能力相對弱一些，配置中心使用了攜程開發的Apollo。

• 第二套是博雲根據客戶需求自研的基於GRPC的微服務框架，可以支援多語言，未來也會支援Istio。

基於gRPC的框架主要用到ZooKeeper，也是用了Kong做API閘道器，跟gRPC做整合。因為gRPC本身是一個RPC框架，沒有一套完整的服務治理，所以博雲就自研了一套針對多語言微服務框架。目前BeyondMS微服務平臺已經在多個金融機構落地應用。

微服務架構演進方式

說到微服務架構的演進，趙安全比較認同微服務是長出來的，而不是設計出來的。完全架空地去做一套新系統當然可以做好微服務架構，但是很多時候我們沒有這種條件，都是在一個已有的系統裡去做。這樣我們的架構演進方式就是：有了新需求，做一個獨立的微服務，慢慢做成服務化互相呼叫，然後把資料切分過來。但資料切分也不是一次就做完了，而是資料先在新老系統裡都有，兩邊保持一致，慢慢地把資料遷移到新系統裡去。最後的結果可能是原來的老系統還保留有一些東西，但是在它周邊的很多新需求，全都是通過一個個獨立微服務來做出來的，這就是微服務長出來的方式。

在專案的落地中，這種架構演進方式還是有很多風險的，也經常有客戶採用完全中心開發的方式做微服務，比較簡單純粹，但需要多花很多成本。

微服務是需要大平臺支撐的

微服務革新了軟體的生產過程，包括開發、測試和部署各個階段。但服務的切分並不是要遵守單一原則，因為未來的服務不可能完全垂直切分。從另外一個角度看，微服務的過程其實也是工業化的工程，每個微服務都是生產線上的一個零件，但要注意，零件的組裝和拼接難度更大，所以在談論微服務時一定要注意，它是需要一個大平臺支撐的。

BoCloud博雲也有自己的企業級PaaS整體解決方案，整個PaaS平臺底層是容器平臺，它是PaaS中的一個基礎設施；再上一層有應用的開發管理，應用的部署上線，以及應用的執行管理和開發管理。

微服務的開發框架就跟開發管理相關。此外博雲還提供微服務諮詢，這屬於解決方案的一部分，包括了微服務拆分設計的諮詢，以及微服務框架選型和微服務的開發指導。這兩者屬於開發過程管理。

對於微服務的釋出上線和微服務執行的管理，博雲提供了服務治理。監控和服務治理，是雲平臺管理的一個比較重要的方面。微服務上線是容器平臺的事情，微服務執行管理就涉及到服務治理。

企業應該如何提升團隊的微服務落地能力？

通過對自身服務案例的總結，趙安全也對企業提升微服務落地的能力給出了自己的建議。整體來講，要做微服務，最重要的是整個團隊要達成共識。現在開發團隊經常會聽到兩種聲音，第一種聲音希望藉助新技術，發展新東西，另外一種聲音是希望按部就班什麼都不要變。第一種聲音和微服務是比較匹配的，第二種聲音對微服務是一種阻力。

所以首先大家還是要達成共識。很多時候微服務架構的改造都是試點專案，這就需要有願意嘗試新東西的人來做這樣的事情。從企業落地來講，如果第一個專案做失敗了，後面很長一段時間內很多就沒有機會了。

第二點是團隊要有心理準備，提前做知識儲備。因為微服務對開發、測試人員都帶來了挑戰，大家如果都沒有儲備的話，可能就需要多花很多時間。

總結

分散式計算和雲端計算給IT基礎設施帶來了巨大的變革，引領著這一輪的數字化轉型。面對眾多的事務，彈性擴充套件的需求，微服務架構已經在雲端計算時代C位出道，滿足我們的諸多需求。

微服務之路的想法是好的，但是在追趕微服務浪潮之前企業和團隊應該負責任地進行考慮，做好權衡取捨，切忌盲目跟風。微服務架構首先要關注的不是RPC、Service Discovery這些概念，也不是Eureka、Zipkin這些技術框架，而是服務的邊界、職責劃分，劃分錯誤就會陷入大量的服務間的相互呼叫和分散式事務中，這種情況微服務帶來的不是便利而是麻煩。

所以，微服務轉型，你準備好了嗎？

作者簡介

趙安全，博雲高階解決方案架構師，在IT架構和雲端計算等領域有超過12年的豐富經驗，認證DevOps Master。先後負責過民生銀行、江蘇銀行、佰仟金融、中石油等容器雲/Devops專案的技術方案、架構設計、落地諮詢等工作。對雲端計算、DevOps、分散式架構有深入的研究和理解。