建站
咨詢
售后
建站咨詢
新聞中心
【稿件】微服務(wù)是一個比較大的話題，基于我的過往經(jīng)歷，本文將以 Netflix 為例，分享一個大型互聯(lián)網(wǎng)公司如何從一個 Monolithic 的 APP 成功轉(zhuǎn)型到微服務(wù)。文章主要涉及微服務(wù)的產(chǎn)生歷史，應(yīng)用場景，與單片服務(wù)區(qū)別，微服務(wù)帶來的技術(shù)、企業(yè)組織結(jié)構(gòu)等方面挑戰(zhàn)，以及如何合理地選擇單片服務(wù)構(gòu)架和微服務(wù)構(gòu)架等內(nèi)容。
創(chuàng)新互聯(lián)建站長期為1000+客戶提供的網(wǎng)站建設(shè)服務(wù)，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為鳳城企業(yè)提供專業(yè)的成都網(wǎng)站建設(shè)、做網(wǎng)站，鳳城網(wǎng)站改版等技術(shù)服務(wù)。擁有10余年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
微服務(wù)的產(chǎn)生歷史
如下圖，是微服務(wù)在 Google 的搜索結(jié)果：
自 2014 年以來，微服務(wù)開始被關(guān)注，搜索的人越來越多，并在 2016 年左右達到頂峰。從地域來看，很多國家都在關(guān)注，如印度，歐洲等等，并且很多公司在使用微服務(wù)構(gòu)架。以下以 Netflix 為例來分享微服務(wù)的演變過程以及帶來的挑戰(zhàn)。
Netflix 的微服務(wù)演化
我 2012 年加入Netflix，從中了解到：
- Netflix 從 2008 到 2009 年就開始在自有數(shù)據(jù)中心做單片的 Web 應(yīng)用，那個時期是很龐大的 Java 包，無數(shù)的程序?qū)懺谄渲?，造成很多問題。
- 2010 年開始把重量級的部分轉(zhuǎn)出。
- 2013 到 2014 年，其他的模塊也陸續(xù)轉(zhuǎn)出，并發(fā)布很多 Open Source 的微服務(wù)工具，在硅谷及全球受到很多人的關(guān)注。
- 直至 2015 年左右，Netflix 基本完成向微服務(wù)的轉(zhuǎn)型，也徹底從自有數(shù)據(jù)中心，轉(zhuǎn)移到亞馬遜的云平臺。
如下，是微服務(wù)示意圖：
微服務(wù)看上去很復雜，其實它是一個個服務(wù)器組成的，這些服務(wù)器之間相互連接。
如下圖，是 Netflix 在微服務(wù)方面的使用情況：
從時間點看，Netflix 是硅谷采用微服務(wù)比較早的公司，在采用過程中也受到很多質(zhì)疑，特別是傳統(tǒng)公司，從數(shù)據(jù)中心遷到云上，需要時間來慢慢接受。
微服務(wù)、單片服務(wù)兩者的概念與區(qū)別
如下，是很普遍的 Monolithic APP 示意圖：
從 powser 到各種公司的 Apache，形成一個包含各種功能的 WAR 包，最后是一個 MySQL 的存儲層。這樣的方式，比較易于測試，部署方面也很簡單。
Monolithic APP 的優(yōu)點如下：
- 易于開發(fā)。很多 IDE 和框架都支持，比如 Sprint MVC、Ruby Rails、Python Django 等。
- 易于測試?？梢酝ㄟ^簡單啟動應(yīng)用程序并使用 Selenium 測試 UI 來實現(xiàn)端到端測試。
- 易于部署。只需將打包的應(yīng)用程序復制到服務(wù)器。
- 易于擴展。通過在負載平衡器后運行多個副本，可以輕松地水平擴展。
- DevOps 比較簡單。一支專門 DevOps 團隊負責即可。
Monolithic APP 的缺點如下：
- 應(yīng)用程序太大且復雜，很難完全理解并快速正確地進行更改。
- 應(yīng)用程序會越變越大，可能會減慢啟動時間。
- 必須在每次更新時重新部署整個應(yīng)用程序。
- 如果代碼庫有新的變化，變化的影響通常不是很清楚，這導致廣泛的手動測試。
- 連續(xù)部署很困難。
- 當不同模塊具有沖突的資源需求時，單片應(yīng)用也可能難以擴展。
- 可靠性差。任何模塊中的錯誤（例如內(nèi)存泄漏）都可能會導致整個網(wǎng)站宕機。此外，由于應(yīng)用程序的所有實例是相同的，該錯誤將影響整個應(yīng)用程序的可用性。
- 采用新技術(shù)或框架很困難。由于框架或語言的變化將影響整個應(yīng)用程序，因此在時間和成本上都是非常昂貴的。
隨著代碼庫，組件和團隊規(guī)模增長，各種問題相繼出現(xiàn)。
主要概括為如下幾點：
- 原代碼太大，IDE 打不開了。
- 單機的內(nèi)存不夠，沒法編譯和跑代碼。
- 部署一次要花很長時間。
- 開發(fā)速度跟不上產(chǎn)品的需求，一個小小的變化需要整個源代碼重新編譯。
- 某一個模塊里的一個小錯誤，可能導致整個網(wǎng)站宕機。
隨著組織的成長，功能的增多以及技術(shù)棧的瓶頸出現(xiàn)，需要有新的變革。但面對如此龐大的視頻網(wǎng)站，有的程序都是用的 Java 包，自有數(shù)據(jù)中心，當時還沒有微服務(wù)的概念，但已經(jīng)有了把內(nèi)容拆分出來的意識。
什么是微服務(wù)？
“微”是指團隊、代碼行數(shù)或 API 端口的數(shù)目等指標的大?。慷疾皇?，不同人對微服務(wù)有不同定義。
個人比較贊同這個描述：Loosely coupled service orientedarchitecture with bounded contexts。
關(guān)鍵是 LOOSELY COUPLED和BOUNDED TEXT，LOOSELY COUPLED 意味著每個服務(wù)可以獨立更新，BOUNDED TEXT 意味著一個服務(wù)只要做自己的事情，外界以API等接口。
也就是微服務(wù)要實現(xiàn)獨立部署，擁有獨立技術(shù)棧、界定上下文，明確的所有權(quán)等特點。
微服務(wù)與單片服務(wù)的對比
如下，是微服務(wù)與單片服務(wù)很形象的對比圖：
單片服務(wù)是把所有的東西放在一個大盒子里，這個大盒子里什么都有。微服務(wù)更像是車箱，每個箱子里包含特定的功能模塊和物品，所有東西可以很靈活地拆分出來。
也就是說，在 Monolithic APP 中，所有的部件都在一個巨大的軟件包中。在微服務(wù)的構(gòu)建下，有很多獨立存在的小服務(wù)，通過 API 接口連接成大的系統(tǒng)。
如下圖，是 Monolithic APP 的架構(gòu)：
Netflix 會支撐很多設(shè)備，最初是所有設(shè)備通過一個負載均衡器到一個碩大的、什么都包含的程序中，最后會成為一個碩大的 Oracle 數(shù)據(jù)中心。這樣一來，會產(chǎn)生很大問題，大家都很反感。
如下圖，是微服務(wù)的架構(gòu)：
上圖可以看出每個服務(wù)都可拆分，自有數(shù)據(jù)源，不一定是 Oracle，可根據(jù)業(yè)務(wù)場景用不同的數(shù)據(jù)庫，完全由各個團隊自己決定。
綜上是從技術(shù)角度分析 Netflix 為什么選擇微服務(wù)，從商業(yè)角度來看 Netflix 選擇微服務(wù)的原因如下。
有三點原因：
- 可用性(Availability)。24 x 7 防止單點失?。╯ingle point of failure）。在巨大的 CODEBASE 情況下，經(jīng)常一個小小的錯誤比如代碼中多加了一個冒號就會導致整個程序編譯不了甚至引起整個網(wǎng)站宕機。對于大型互聯(lián)網(wǎng)公司而言，一定要避免單片服務(wù)導致的宕機。
- 可拓展性。Netflix 當時流量占到美國三分之一，超過 9000W 的付費用戶且增長非?？?。一旦某部件達到瓶頸時要有迅速可拓展的能力，一般就是添加新機器讓它運轉(zhuǎn)。但在傳統(tǒng)單片服務(wù)上，整個部分綁定在一起，擴展非常困難。
- 速度。對互聯(lián)網(wǎng)公司，特別是 ToC 需要快速推出，速度很重要。速度在互聯(lián)網(wǎng)時代是致勝的關(guān)鍵。
- 大型互聯(lián)網(wǎng)公司推行微服務(wù)，一旦需要新功能，可立即新開一個微服務(wù)，或在幾個有限的微服務(wù)中進行改動，不需要像原來基于巨大的數(shù)據(jù)庫來改動。
微服務(wù)帶來的技術(shù)挑戰(zhàn)
軟件構(gòu)架從單片服務(wù)向微服務(wù)轉(zhuǎn)型過程中帶來了很大的技術(shù)挑戰(zhàn)。下面選取自認為比較關(guān)鍵的內(nèi)容進行分享。
主要涉及以下幾方面的挑戰(zhàn)：
- 服務(wù)發(fā)現(xiàn)(Service discovery)。傳統(tǒng)單片服務(wù)相對簡單，但微服務(wù)有幾百上千的服務(wù)器，對用戶來講，服務(wù)器的選擇是個問題。
- 運維復雜度增加 – DevOps。
- 分布式系統(tǒng)本質(zhì)上帶來的復雜度。
- 網(wǎng)絡(luò)延遲，容錯。
- 服務(wù)接口版本控制，存在不匹配。
- 測試（需要整個生態(tài)系統(tǒng)來測試）。
- FAN OUT - >增加網(wǎng)絡(luò)流量。
面對這些方面的挑戰(zhàn)，分享一些關(guān)鍵技術(shù)，如 Service discovery、服務(wù)注冊、服務(wù)注冊模式、瓶頸/熱點、熔斷器和測試等。
Service discovery
對用戶而言，最難抉擇的是去哪個服務(wù)器上取數(shù)據(jù)，解決方案有客戶端發(fā)現(xiàn)和服務(wù)器端發(fā)現(xiàn)兩種。
如下圖，是客戶端發(fā)現(xiàn)：
客戶端發(fā)現(xiàn)，就是客戶端布設(shè) Service Instance，存放所有地址、各種信息。客戶端接收到數(shù)據(jù)之后，可自行判斷去哪臺服務(wù)器上獲取信息。
如下圖，是服務(wù)端發(fā)現(xiàn)：
客戶端不需要寫很多程序，而是通過 Load Balancer 把信息轉(zhuǎn)到某個服務(wù)器。
服務(wù)注冊
服務(wù)注冊表是服務(wù)發(fā)現(xiàn)的關(guān)鍵部分，是一個包含服務(wù)實例的網(wǎng)絡(luò)位置的數(shù)據(jù)庫，需要高度可用且是最新的。
服務(wù)注冊一定不能宕機，一旦出現(xiàn)問題，恢復非常困難。服務(wù)注冊和發(fā)現(xiàn)部分，Netflix 采用的是自研 Eureka 組件。
服務(wù)注冊模式
服務(wù)注冊模式分為自注冊和第三方注冊兩種：
自注冊模式。這種方法的一個很好的例子是 NetflixOSS Eureka 客戶端。Eureka 客戶端處理服務(wù)實例注冊和注銷的所有方面。
Spring Cloud 項目實現(xiàn)了各種模式，包括服務(wù)發(fā)現(xiàn)，可以輕松地使用 Eureka 自動注冊服務(wù)實例，只需使用 @EnableEurekaClient 注釋注釋您的 Java 配置類。
服務(wù)注冊模式相對簡單，并且不需要任何其他系統(tǒng)組件。但它將服務(wù)實例耦合到服務(wù)注冊表。您必須在您的服務(wù)使用的每種編程語言和框架中實現(xiàn)注冊碼。
如下圖，是第三方注冊模式：
開源注冊器項目—經(jīng) Registrator，會自動注冊和注銷部署為 Docker 容器的服務(wù)實例，支持多個服務(wù)注冊表，包括 etcd 和 Consul。
NetflixOSS Prana 主要用于以非 JVM 語言編寫的服務(wù)，它是與服務(wù)實例并行運行的邊路應(yīng)用程序。 Prana 使用 Netflix Eureka 注冊和注銷服務(wù)實例。
Registrator 的優(yōu)點是服務(wù)與服務(wù)注冊表斷開連接，不需要為開發(fā)人員使用的每種編程語言和框架實現(xiàn)服務(wù)注冊邏輯。
相反，在專用服務(wù)內(nèi)以集中方式處理服務(wù)實例注冊。缺點是除非它內(nèi)置在部署環(huán)境中，它是另一個高可用性的系統(tǒng)組件，需要設(shè)置和管理。
如何處理 FAN OUT
如下圖所示，單片服務(wù)里請求只有一個，而微服務(wù)里很多時候客戶端必須通過不同的微服務(wù)器才能把數(shù)據(jù)全部收集起來，請求繁多。
如下圖所示，解決的方法就是 Cache：
盡量把已經(jīng)擁有的數(shù)據(jù) Cache 起來，當訪問時，優(yōu)先于 Cache，沒有再選擇其他部分。
瓶頸/問題
如下圖，當遇到整個服務(wù)中某個變成瓶頸的情況，就會調(diào)用 X，X 要從用戶帳戶里拿數(shù)據(jù)。X 調(diào)用 Y，Y 也要從用戶帳戶里拿數(shù)據(jù)。
這樣一來，用戶服務(wù)會變成一個大大的瓶頸，一旦宕機，最前端的APP一定拿不到數(shù)據(jù)。
處理方法如下圖所示：
Netflix 用的比較多的方法是針對一些共用的數(shù)據(jù)不進行反復調(diào)用，可采用 HTTP HEADER 傳遞數(shù)據(jù)。
如何提高可用性（Availability）？
微服務(wù)并不一定能保證可用性，甚至有時微服務(wù)做不好更容易宕機，所以一定要采用一些好的容錯機制。
所謂容錯，原則上說就是當錯誤發(fā)生，盡可能讓一臺服務(wù)器宕機。常見的解決方式有 Time out、Circuit peaker(熔斷器)和 Bulkheads (艙壁)-Reject new request 三種。
熔斷器在 Netflix 用的比較多，如下兩圖所示，為熔斷流程：
熔斷器主要應(yīng)用在當一個服務(wù)去它的下游服務(wù)拿數(shù)據(jù)時，不應(yīng)該直接拿，要通過一個熔斷程序。
當下游服務(wù)出現(xiàn)錯誤，或延時很長時間，熔斷器就停止再到下游服務(wù)拿數(shù)據(jù)，直接返回。熔斷器也會不斷進行判斷，服務(wù)是否恢復，恢復之后才會繼續(xù)拿取數(shù)據(jù)。
這樣一來，問題就會在某個地方被阻擋，不會出現(xiàn)服務(wù)接連問題，導致微服務(wù)出現(xiàn)大規(guī)模崩潰的現(xiàn)象。
微服務(wù)測試
測試是比較頭疼的環(huán)節(jié)，特別是微服務(wù)架構(gòu)端到端變得特別困難，主要原因是幾百個服務(wù)隸屬于不同的團隊。
個人比較推薦單元測試（Unit Test）、服務(wù)測試（Service Test）。而端對端測試（End to End Test）要盡量避免，可以通過一些監(jiān)控工具來完成。
還有 Netflix 采用 ChaosMonkey 工具來對延遲和服務(wù)可靠性進行測試。這里值得注意的是，每個微服務(wù)至少要有三個實時備份，以免宕機后無法恢復。
微服務(wù)帶來的企業(yè)組織結(jié)構(gòu)挑戰(zhàn)
之所以分享微服務(wù)帶來的企業(yè)組織結(jié)構(gòu)挑戰(zhàn)，是因為歸根結(jié)底還是人在做事。微服務(wù)是去中心化，讓每個服務(wù)有獨立權(quán)，這樣會導致組織結(jié)構(gòu)發(fā)生很大的變化。
企業(yè)的組織構(gòu)架往往會反映在技術(shù)構(gòu)架中，微服務(wù)在企業(yè)內(nèi)部是否能夠成功，很大程度上取決于企業(yè)的組織構(gòu)架和技術(shù)構(gòu)架是否能夠匹配。
以 Netflix 為例，分享在向微服務(wù)構(gòu)架轉(zhuǎn)變的過程中對團隊和企業(yè)構(gòu)架帶來的挑戰(zhàn)。
優(yōu)化速度，而不是效率
Netflix 在考量以速度還是以效率為優(yōu)化核心，最終選擇了速度。因為速度是贏得市場最重要的因素，速度意味著了解客戶需求，并以比競爭對手更快的速度給予他們想要的東西。在競爭對手準備跟進的時候，已經(jīng)轉(zhuǎn)到下一組改進。
速度和效率是什么關(guān)系呢？強調(diào)效率通常意味著試圖控制開發(fā)過程的整體流程，以消除重復的工作并避免錯誤的同時注意降低成本。
常見的結(jié)果是，注重節(jié)流，而不是開源。如果你說“我這樣做是因為它更有效率”，那么這個意想不到的結(jié)果就是讓你慢下來。
這不是鼓勵浪費和重復開發(fā)，但是應(yīng)該先優(yōu)化速度，效率成為次要。提高效率不是一個企業(yè)的終極目標，提高效率要以業(yè)務(wù)增長更快為結(jié)果。
以結(jié)果為導向，減少不必要流程
盡量增加每個微服務(wù)團隊的自由度，如開發(fā)工具，開發(fā)流程等方面，然后以結(jié)果為導向。
Netflix 有三個框架，其中 Java 占主流，每個團隊可根據(jù)自身情況選擇技術(shù)構(gòu)架，甚至數(shù)據(jù)庫也可選擇 MySQL 或者 NoSQL。
盡量減少流程，為什么有流程呢？流程往往是對過去的事情的總結(jié)，如對一些錯誤，經(jīng)驗總結(jié)，之后用這個進行流程控制。
但過多的流程會減慢對新生事物和突發(fā)情況的反映速度。還有要明確每個團隊的目標，減少互相依賴關(guān)系。
如下圖，是傳統(tǒng)公司的產(chǎn)品開發(fā)流程：
大多數(shù)軟件開發(fā)團隊呈孤島狀，他們之間沒有人員重疊。軟件開發(fā)項目的標準過程從與用戶體驗和開發(fā)組的產(chǎn)品經(jīng)理召開會議開始，一塊討論新功能的想法。
在代碼中實現(xiàn)該思想之后，代碼被傳遞給質(zhì)量保證（QA）和數(shù)據(jù)庫管理團隊，經(jīng)常需要進行很多溝通。與系統(tǒng)、網(wǎng)絡(luò)和SAN管理員的溝通往往是通過內(nèi)部的 TICKET 系統(tǒng)，導致整個過程非常緩慢。
有些公司試圖用初創(chuàng)公司的形式開發(fā)產(chǎn)品，但初創(chuàng)公司開發(fā)團隊并不一定是微服務(wù)開發(fā)團隊。公司雖會有很多個小的初創(chuàng)公司形式的小團隊，但是每個團隊內(nèi)部結(jié)構(gòu)還是和傳統(tǒng)公司的團隊結(jié)構(gòu)一樣。
如下圖，是微服務(wù)產(chǎn)品研發(fā)團隊：
微服務(wù)產(chǎn)品研發(fā)團隊沒有不同的產(chǎn)品經(jīng)理、UX 經(jīng)理、開發(fā)經(jīng)理等，在其孤島中向下管理。
每個產(chǎn)品功能（實現(xiàn)為微服務(wù)）都有一名經(jīng)理，他負責監(jiān)督一個團隊，從構(gòu)思到部署來處理各個方面微服務(wù)的軟件開發(fā)。
平臺團隊提供產(chǎn)品團隊通過 API 訪問的基礎(chǔ)架構(gòu)支持，在整個過程中，都采用 DeVop 形式發(fā)布和維護產(chǎn)品。
如何合理地選擇單片服務(wù)構(gòu)架和微服務(wù)構(gòu)架
并不是所有的場景都適合微服務(wù)，要根據(jù)實際情況，選擇微服務(wù)或單片服務(wù)：
微服務(wù)適用于巨大流量、系統(tǒng)有一定復雜性、需要快速開發(fā)出新的產(chǎn)品、用戶數(shù)量增長迅速以及絕大多數(shù) TOC 的互聯(lián)網(wǎng)公司。
單片服務(wù)的應(yīng)用場景一般是流量比較小、功能單一或非常簡單、不會快速迭代以及企業(yè)內(nèi)部工具，POC 工具或網(wǎng)站。
前樂視美國視頻平臺技術(shù)總監(jiān)以及Netflix 視頻內(nèi)容平臺技術(shù)負責人。有 15 年以上互聯(lián)網(wǎng)公司（LinkedIn、樂視、Netflix 以及 PayPal）技術(shù)開發(fā)、構(gòu)架以及團隊管理的經(jīng)驗。主要負責的領(lǐng)域是高并發(fā)后端服務(wù)構(gòu)架、微服務(wù)構(gòu)架、大數(shù)據(jù)平臺構(gòu)架等，以及端對端的整個產(chǎn)品開發(fā)。感興趣的領(lǐng)域是視頻，支付，互聯(lián)網(wǎng)金融以及電商領(lǐng)域。
以上內(nèi)容根據(jù)羅軼民老師在 WOTA2017 “微服務(wù)架構(gòu)”專場的演講內(nèi)容整理。
【原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為.com】
本文題目：15年資深架構(gòu)師詳解：一個大型互聯(lián)網(wǎng)公司的微服務(wù)轉(zhuǎn)型實踐
URL分享：http://www.dlmjj.cn/article/djcphgc.html
