【轉】微服務架構實踐經驗分享

服務的瘋狂增加與雲計算技術的進步，讓微服務架構受到咱們的重點關注。在近日的七牛開發者最佳實踐日上，七牛技術總監肖勤介紹了本人在微服務架構方面的實踐經驗，並接受了CSDN記者的採訪，分享了我的職業經歷心得以及如何看待雲服務，微服務架構和Docker、Kubernetes的發展等。

微服務架構優點

肖勤首先簡單介紹了微服務（Microservices）的內涵及優點，他表示，微服務架構的本質，是用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題。

 

微服務架構將服務拆分，分別採用相對獨立的服務對各方面進行管理，彼此之間使用統一的接口來進行交流，架構變得複雜，優點也很明顯：

 

• 複雜度可控：在將應用分解的同時，規避了本來複雜度無止境的積累。每個微服務專一於單一功能，並經過定義良好的接口清晰表述服務邊界。因爲體積小、複雜度低，每一個微服務可由一個小規模開發團隊徹底掌控，易於保持高可維護性和開發效率。

• 獨立部署：因爲微服務具有獨立的運行進程，因此每一個微服務也能夠獨立部署。當某個微服務發生變動時無需編譯、部署整個應用。由微服務組成的應用至關於具有一系列可並行的發佈流程，使得發佈更加高效，同時下降對生產環境所形成的風險，最終縮短應用交付週期。

• 技術選型靈活：微服務架構下，技術選型是去中心化的。每一個團隊能夠根據自身服務的需求和行業發展的現狀，自由選擇最適合的技術棧。因爲每一個微服務相對簡單，當須要對技術棧進行升級時所面臨的風險較低，甚至徹底重構一個微服務也是可行的。

• 容錯：當某一組建發生故障時，在單一進程的傳統架構下，故障頗有可能在進程內擴散，造成應用全局性的不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其餘服務可經過重試、平穩退化等機制實現應用層面的容錯。

• 擴展：單塊架構應用也能夠實現橫向擴展，就是將整個應用完整的複製到不一樣的節點。當應用的不一樣組件在擴展需求上存在差別時，微服務架構便體現出其靈活性，由於每一個服務能夠根據實際需求獨立進行擴展。

微服務架構實踐

肖勤介紹重點介紹了七牛圖片處理（FOP）場景的微服務應用。FOP服務早期的架構以它的每個應用爲後端。隨着用戶愈來愈多，流量愈來愈高，負載均衡逐漸出現了帶寬和流量的壓力。

七牛將圖像處理服務拆成兩個部分，分別負責處理文件的傳輸和圖像自己的處理。從負載均衡過來的請求再也不是完整的文件，而是文件的地址。這樣，負載均衡和流量優化跟整個圖像處理沒有關係，能夠作單獨的部署。而對於稍微複雜一些的請求（如圖片格式和尺寸的變動，添加水印），就用管道的方式把不一樣的服務串聯起來最終實現。

核心技術：Maven,Springmvc mybatis shiro, Druid, Restful, Dubbo, ZooKeeper,Redis,FastDFS,ActiveMQ,Nginx 
1.     項目核心代碼結構截圖

   項目模塊依賴

特別提醒：開發人員在開發的時候能夠將本身的業務REST服務化或者Dubbo服務化

2.    項目依賴介紹

   2.1 後臺管理系統、Rest服務系統、Scheculer定時調度系統依賴以下圖：
 

       2.2 Dubbo獨立服務項目依賴以下圖：

 

3.  項目功能部分截圖：

 

 

 

 

 

 

 

 

zookeeper、dubbo服務啓動 

 

 

dubbo管控臺 

 

 

 

 

 

 

 REST服務平臺

 

 

 

 

對話肖勤

CSDN：可否介紹您如今的工做，以及您爲何選擇加入七牛？

肖勤：我在3個月以前加入七牛，目前負責基礎架構運營、部署相關的研發工做，爲基礎架構部門的同事提供支持。

選擇七牛，我很認同七牛的信念和觀點，就是讓雲服務變成和水電煤同樣的基礎服務。可以爲這樣的想法而工做，我以爲仍是挺有意思的。技術工做者在不一樣階段須要關注和選擇不一樣的東西，這就是個人選擇。

CSDN：那您換了兩次工做，也成爲了一名技術管理者，從您的經從來看，在不一樣的時間節點應當關注哪些不一樣的東西，才符合技術人員的成長路徑？

肖勤：剛開始工做的時候，我首先考慮要找到一個可以真正學習技術的平臺，正好有一些熟悉的師兄可以引領我。而後來到一家創業團隊，多數技術人員基本都沒有經驗，我就成爲了技術決策者，把以前積累的經驗變成解決問題的方式。再而後隨着雲計算的發展，我就加入到基礎雲服務的構建當中來。

我認爲，對於初創公司來講，不存在純粹的管理者，技術團隊都是爲產品研發服務的，不可能脫離技術工做。所謂管理，也是針對事情，作研發項目的管理，協調團隊把產品作出來。

對於我的職業發展規劃，我始終認爲，首先必定不能浮躁，時代和技術變化確實都很快，但解決問題的基本技能纔是技術人員的根本；其次須要多交流，包括和同事和老闆的交流，才能更好地發揮本身的聰明才智。

CSDN：如何看待加入七牛的工做的挑戰？

肖勤：從公司層面說，存儲服務基礎很好，但其餘方面的積累相對要少，還須要繼續學習和積累。與此相對應，於我我的而言，背景知識也還有不少須要學習的地方。應對的辦法，我認爲是多讀代碼，讀書，經過項目試驗，以及尖端技術在實踐中的使用來得到進步。

CSDN：您擅長Ruby on Rails，七牛雲存儲其實用Go，您如何看待不一樣的語言和框架的選擇？

肖勤：我我的對開發工具沒有特定的偏好，相信實用至上，不會參與語言的爭論。語言、框架都是工具性的東西，都是爲產品研發服務的，應當由項目決定。Ruby on Rails是不錯的工具，七牛雲存儲用的Go語言，前端以AngularJS爲主，也都很是成熟。七牛公司內部已經有不少的積累，因此也不必再造車輪。

CSDN：另外做爲之前的雲服務使用者，如今的雲服務提供者，您感受有哪些不一樣？

肖勤：雲的基礎服務的發展成熟，可以爲企業尤爲是創業者提供很更好的機會。藉助雲服務提供者作出的專業服務分擔一些事情，企業和創業者就能夠有更多的精力投入到本身的核心價值上去，商業上創業成功的可能性會更大。但這須要雲產品符合業務運營的邏輯。

做爲雲服務提供者，我須要保證構建的功能是用戶真正需求的。而有了雲服務使用者的經歷，我可以更好地理解爲何用戶會關心某些功能，哪些功能作得還不夠好。這對雲服務質量的提高頗有幫助。

 

CSDN：您今天談到的微服務架構是否表明雲服務的成熟？用戶如何肯定在哪一種狀況下須要使用微服務架構，哪一種狀況下不能使用微服務架構？

肖勤：對於作好事情、維護好產品而言，微服務架構不是惟一的方向，可是它是一個比較靠譜的思路和方向。若是你把全部的東西放到一塊兒，都本身來作，勢必須要不少資源來維護它，若是拆分開，把一些基礎服務部件交給專業作基礎服務的人來作，成本一般會比本身作的要低得多。要利用好雲計算資源，服務就是拆分越細越好。

對於創業團隊來講，我我的認爲，沒必要刻意去追求微服務。尤爲在創業初期，首先須要把產品作出來，等到方向獲得驗證，服務愈來愈複雜，團隊愈來愈龐大以後，再適當放慢腳步，考慮團隊架構、產品架構的調整，如何可以用一樣的資源作更多的事情。

CSDN：可否介紹微服務架構目前在七牛發揮的做用？

肖勤：微服務架構在七牛如今已是一個潛移默化的影響。微服務架構不只僅是描述技術架構，一樣也是描述團隊架構。就像一種服務的精神，你要注意構建、運營和管理這個服務，這樣一種精神在團隊中是很是有益的，每一個人對本身的職責都可以更加清晰地認識，從而發揮主觀能動性，包括運營、後期的改進，可以自發地去提高，團隊的管理就會更加輕鬆，效率也會更高。

CSDN：拆分服務遷移到微服務架構，有沒有通用的步驟？

肖勤：首先，企業要有一致的想法，認同微服務架構帶來的好處。

其次，這個過程要按部就班，不能操之過急。不必定是方向的問題，而是執行過程的問題。先挑選邊緣的服務、基礎性的服務、可替代性強的服務，它們用基礎雲服務替代，而不是本身維護，或者把多項業務的共通部分拆出來，用少數人來維護，看看這樣作是否真的有好處，切實解決問題，節約資源，在有好處驅動的狀況下，再決定推動架構變革。若是架構比較特殊，不適合微服務，經過邊緣服務的嘗試，能夠及時發現問題。

CSDN：對於微服務帶來的複雜性，包括不一樣服務之間的聯繫和依賴關係等等，用戶還有哪些須要特別注意的地方？

肖勤：服務的分拆確定會讓結構更加複雜，但微服務在理念描述上已經意識到，從服務架構着眼，設計上考慮了部署的問題，運營在架構中的優先級也是排在第一位的，而以往在設計模式、軟件架構基本不會考慮到部署、運營的問題。因此，若是要支持微服務架構，必須有一套行之有效的運營、部署的工具和方式，這也是容器相關技術和容器雲如今備受關注的一個緣由。

依賴的問題，包括一部分的複雜性問題，取決於拆分時候邊界和接口的定義、數據聯通的方式，設計得是否是足夠合理，服務提供者是否是清楚需求的方式，服務調用者是否是理解接口的意圖，也就是說團隊針對每一個服務的溝通，對事情的定位，對接口的抽象，是否是有一個一樣的認知水平，達成一個共識。只要保證接口穩定、合理，實現無論怎麼變化，對整合架構就不會有負面影響。服務的局部修改反而能夠更快速，由於不會涉及一個大系統的調整。

因此說，不能爲了拆分而拆分，拆分的意圖要準確描述問題的解決。在一個系統裏面，定義接口比怎麼實現更重要，不要設計很差理解、不合理的接口。

CSDN：談到容器，您如何看待Docker的興起給微服務架構帶來的機遇和挑戰？

肖勤：當前的容器市場很熱鬧，但Docker仍是最具表明性的容器技術，微服務架構的主流技術方案中都使用了Docker，它的一些特性如隔離性、物理機制等和微服務架構有自然的契合度。可是Docker並不能解決微服務的全部問題，它最初是一個單機的工具，雖而後來官方也推出了不少的工具鏈，要真正解決部署的問題，還有很長的路要走。

CSDN：具體到實操，您推薦採用哪些工具？

肖勤：咱們在考察中發現，Google開源的容器集羣管理系統，設計的思路很不錯，畢竟Google在這方面是很是領先的，它的容器集羣已經成熟應用。使用Kubernetes部署微服務，用戶須要的只是定義服務的狀態，而不是部署過程。整個調度的過程、提供服務的過程都由系統自動實現。

 

須要說明的是，雖然Kubernetes目前已經發布1.0版本，它在如今的階段能爲咱們提供一個很好的工具，但它不必定是將來，它也有必定的侷限性。例如，Kubernetes的設計，Pod的網絡與Gloogle雲服務高度整合，若是不用GCE，用戶還須要本身作不少的工做纔能有好的網絡服務。這須要企業先去嘗試，看看是否是適合自身的狀況。