服務的瘋狂增長與云計算技術的進步,讓微服務架構遭到我們的重點關注。在近日的7牛開發者最好實踐日上,7牛技術總監肖勤介紹了本人在微服務架構方面的實踐經驗,并接受了恩威科技(微信公眾號:天府云創)記者的采訪,分享了個人職業經歷心得和如何看待云服務,微服務架構和Docker、Kubernetes的發展等。
肖勤首先簡單介紹了微服務(Microservices)的內涵及優勢,他表示,微服務架構的本質,是用1些功能比較明確、業務比較精練的服務去解決更大、更實際的問題。
微服務架構將服務拆分,分別采取相對獨立的服務對各方面進行管理,彼此之間使用統1的接口來進行交換,架構變得復雜,優勢也很明顯:
肖勤介紹重點介紹了7牛圖片處理(FOP)場景的微服務利用。FOP服務初期的架構以它的每個利用為后端。隨著用戶愈來愈多,流量愈來愈高,負載均衡逐步出現了帶寬和流量的壓力。
7牛將圖象處理服務拆成兩個部份,分別負責處理文件的傳輸和圖象本身的處理。從負載均衡過來的要求不再是完全的文件,而是文件的地址。這樣,負載均衡和流量優化跟全部圖象處理沒有關系,可以做單獨的部署。而對略微復雜1些的要求(如圖片格式和尺寸的變更,添加水印),就用管道的方式把不同的服務串連起來終究實現。
CSDN:能否介紹您現在的工作,和您為何選擇加入7牛?
肖勤:我在3個月之前加入7牛,目前負責基礎架構運營、部署相干的研發工作,為基礎架構部門的同事提供支持。
選擇7牛,我很認同7牛的信心和觀點,就是讓云服務變成和水電煤1樣的基礎服務。能夠為這樣的想法而工作,我覺得還是挺成心思的。技術工作者在不同階段需要關注和選擇不同的東西,這就是我的選擇。
CSDN:那您換了兩次工作,同樣成為了1名技術管理者,從您的經歷來看,在不同的時間節點應當關注哪些不同的東西,才符合技術人員的成長路徑?
肖勤:剛開始工作的時候,我首先斟酌要找到1個能夠真正學習技術的平臺,正好有1些熟習的師兄能夠引領我。然后來到1家創業團隊,多數技術人員基本都沒有經驗,我就成了技術決策者,把之前積累的經驗變成解決問題的方式。再然后隨著云計算的發展,我就加入到基礎云服務的構建當中來。
我認為,對初創公司來講,不存在純潔的管理者,技術團隊都是為產品研發服務的,不可能脫離技術工作。所謂管理,也是針對事情,做研發項目的管理,調和團隊把產品做出來。
對個人職業發展計劃,我始終認為,首先1定不能浮躁,時期和技術變化確切都很快,但解決問題的基本技能才是技術人員的根本;其次需要多交換,包括和同事和老板的交換,才能更好地發揮自己的聰明才干。
CSDN:如何看待加入7牛的工作的挑戰?
肖勤:從公司層面說,存儲服務基礎很好,但其他方面的積累相對要少,還需要繼續學習和積累。與此相對應,于我個人而言,背景知識也還有很多需要學習的地方。應對的辦法,我認為是多讀代碼,讀書,通過項目實驗,和尖端技術在實踐中的使用來取得進步。
CSDN:您善于Ruby on Rails,7牛云存儲其實用Go,您如何看待不同的語言和框架的選擇?
肖勤:我個人對開發工具沒有特定的偏好,相信實用至上,不會參與語言的爭辯。語言、框架都是工具性的東西,都是為產品研發服務的,應當由項目決定。Ruby on Rails是不錯的工具,7牛云存儲用的Go語言,前端以AngularJS為主,也都非常成熟。7牛公司內部已有很多的積累,所以也沒必要再造車輪。
CSDN:另外作為之前的云服務使用者,現在的云服務提供者,您感覺有哪些不同?
肖勤:云的基礎服務的發展成熟,能夠為企業特別是創業者提供很更好的機會。借助云服務提供者做出的專業服務分擔1些事情,企業和創業者就能夠有更多的精力投入到自己的核心價值上去,商業上創業成功的可能性會更大。但這需要云產品符合業務運營的邏輯。
作為云服務提供者,我需要保證構建的功能是用戶真正需求的。而有了云服務使用者的經歷,我能夠更好地理解為何用戶會關心某些功能,哪些功能做得還不夠好。這對云服務質量的提升很有幫助。
CSDN:您今天談到的微服務架構是不是代表云服務的成熟?用戶如何肯定在哪一種情況下需要使用微服務架構,哪一種情況下不能使用微服務架構?
肖勤:對做好事情、保護好產品而言,微服務架構不是唯1的方向,但是它是1個比較靠譜的思路和方向。如果你把所有的東西放到1起,都自己來做,必將需要很多資源來保護它,如果拆分開,把1些基礎服務部件交給專業做基礎服務的人來做,本錢通常會比自己做的要低很多。要利用好云計算資源,服務就是拆分越細越好。
對創業團隊來講,我個人認為,沒必要刻意去尋求微服務。特別在創業早期,首先需要把產品做出來,等到方向得到驗證,服務愈來愈復雜,團隊愈來愈龐大以后,再適當放慢腳步,斟酌團隊架構、產品架構的調劑,如何能夠用一樣的資源做更多的事情。
CSDN:能否介紹微服務架構目前在7牛發揮的作用?
肖勤:微服務架構在7牛現在已是1個潛移默化的影響。微服務架構不單單是描寫技術架構,一樣也是描寫團隊架構。就像1種服務的精神,你要注意構建、運營和管理這個服務,這樣1種精神在團隊中是非常有益的,每一個人對自己的職責都能夠更加清晰地認識,從而發揮主觀能動性,包括運營、后期的改進,能夠自發地去提升,團隊的管理就會更加輕松,效力也會更高。
CSDN:拆分服務遷移到微服務架構,有無通用的步驟?
肖勤:首先,企業要有1致的想法,認同微服務架構帶來的好處。
其次,這個進程要按部就班,不能操之過急。不1定是方向的問題,而是履行進程的問題。先挑選邊沿的服務、基礎性的服務、可替換性強的服務,它們用基礎云服務替換,而不是自己保護,或把多項業務的共通部份拆出來,用少數人來保護,看看這樣做是不是真的有好處,切實解決問題,節儉資源,在有好處驅動的情況下,再決定推動架構變革。如果架構比較特殊,不合適微服務,通過邊沿服務的嘗試,可和時發現問題。
CSDN:對微服務帶來的復雜性,包括不同服務之間的聯系和依賴關系等等,用戶還有哪些需要特別注意的地方?
肖勤:服務的分拆肯定會讓結構更加復雜,但微服務在理念描寫上已意想到,從服務架構著眼,設計上斟酌了部署的問題,運營在架構中的優先級也是排在第1位的,而以往在設計模式、軟件架構基本不會斟酌到部署、運營的問題。所以,如果要支持微服務架構,必須有1套行之有效的運營、部署的工具和方式,這也是容器相干技術和容器云現在備受關注的1個緣由。
依賴的問題,包括1部份的復雜性問題,取決于拆分時候邊界和接口的定義、數據聯通的方式,設計得是否是足夠公道,服務提供者是否是清楚需求的方式,服務調用者是否是理解接口的意圖,也就是說團隊針對每一個服務的溝通,對事情的定位,對接口的抽象,是否是有1個一樣的認知水平,達成1個共鳴。只要保證接口穩定、公道,實現不管怎樣變化,對整合架構就不會有負面影響。服務的局部修改反而可以更快速,由于不會觸及1個大系統的調劑。
所以說,不能為了拆分而拆分,拆分的意圖要準確描寫問題的解決。在1個系統里面,定義接口比怎樣實現更重要,不要設計不好理解、不公道的接口。
CSDN:談到容器,您如何看待Docker的興起給微服務架構帶來的機遇和挑戰?
肖勤:當前的容器市場很熱烈,但Docker還是最具代表性的容器技術,微服務架構的主流技術方案中都使用了Docker,它的1些特性如隔離性、物理機制等和微服務架構有天然的契合度。但是Docker其實不能解決微服務的所有問題,它最初是1個單機的工具,雖然后來官方也推出了很多的工具鏈,要真正解決部署的問題,還有很長的路要走。
CSDN:具體到實操,您推薦采取哪些工具?
肖勤:我們在考察中發現,Google開源的容器集群管理系統,設計的思路很不錯,畢竟Google在這方面是非常領先的,它的容器集群已成熟利用。使用Kubernetes部署微服務,用戶需要的只是定義服務的狀態,而不是部署進程。全部調度的進程、提供服務的進程都由系統自動實現。(固然現在的Mesos固然也是不錯的解決方案)
需要說明的是,雖然Kubernetes目前已發布1.0版本,它在現在的階段能為我們提供1個很好的工具,但它不1定是未來,它也有1定的局限性。例如,Kubernetes的設計,Pod的網絡與Gloogle云服務高度整合,如果不用GCE,用戶還需要自己做很多的工作才能有好的網絡服務。這需要企業先去嘗試,看看是否是合適本身的情況。
【參考瀏覽書籍】
1、《微服務架構與實踐》(王磊)【摘要 書評 試讀】- 京東圖書 http://item.jd.com/11826753.html
2、大型散布式網站架構設計與實踐 PDF掃描版[69MB] 電子書 下載-腳本之家 http://www.jb51.net/books/323694.html