【中美技術專家分享實錄】微服務的挑戰

保證研發團隊的敏捷性催生了微服務的興起，如何從無到有搭建微服務？如何從legacy系統中慢慢改造？是否全部階段的團隊都適合微服務？哪些狀況下不適合使用微服務？咱們請來了三位經歷過改造之痛的嘉賓來分享上述問題。

全網首發·技術乾貨·大咖對話

整理：魔窗丨 10550字丨18分鐘閱讀

來源：本文整理自跨境茶話會線上分享，爲魔窗原創首發。

【主持丨大師兄】：上次咱們作了一個性能優化方面的主題，在主題結束後許多嘉賓都表示對微服務這塊比較感興趣，想多談一下，多吐槽一下，因此咱們此次就定了一個微服務的主題。首先咱們請各位嘉賓作一下自我介紹吧。第一位，葛俊如今是在華爲擔任技術專家，以前在Facebook和微軟都就任過。

【嘉賓丨葛俊】：你們好，我自我介紹一下，我叫葛俊。我以前在美國西雅圖微軟待了六年多，作過開發測試和開發，在Windows和office作。在Facebook作了四年多，主要是作內部開發工具，還有一個叫Nearby Friends的功能。以前我又加入兩個創業公司。如今我在華爲作技術專家。

【主持丨大師兄】：下一位謝東昇是石投的CTO，以前也是在易貝擔任過技術經理。

【嘉賓丨謝東昇】：你們好，我叫謝東昇，我簡單介紹一下我本身。我剛開始其實在一家美國的手機導航公司作系統工程師作了三年半，主要是作服務端Client-Server，使用java進行後端的開發，同時作了一些研發內部工具，好比說迴歸測試的框架，包括咱們系統日誌收集的工具。至關於如今作的一些相似於Kafka的功能，不過那個時候比較笨重，後面就去了eBay，eBay作了大概四年。在eBay剛開始從架構師開始作，主要是作內部工具的一些設計和開發，後面帶了一個團隊，這個團隊也是以開發內部工具爲主，這方面作得比較多一些。後面去了順豐，順豐咱們當時作一個海淘的項目，從順豐開始也是我接觸微服務最多的時候，也是一個起始的階段，後面能夠講得更多一些。在順豐作技術總監，組建了一個技術團隊，包括供應鏈相關的開發和維護。後來去了資邦金服，也是作技術總監，去作一個理財端的平臺。如今在石投金融負責整個技術研發團隊的管理。大概狀況就是這些，謝謝你們！

【主持丨大師兄】：謝謝東昇。接下來張成作一下自我介紹吧。

【嘉賓丨張成】：我是計算所出身，以前也搞過一段時間科研。由於科研的時候其實也是作的搜索引擎相關的，信息檢索相關。後來在百度雲待了一段時間，APP特別火，作整個APP的搜索、分發這個地方。後來就出來本身創業，創業項目其實挺多的，就不細講了。如今是在作招聘領域的一個項目，如今是這邊的技術總監。也是招聘這個項目開始接觸微服務。其實最開始的時候是我跟你們吐槽，說這個微服務有不少的槽點，我今天來主要也是吐槽。謝謝！

【主持丨大師兄】：接下來咱們第一階段仍是請各位嘉賓講一下在本身公司裏面微服務的一些使用經驗，包括一些感觸。

【嘉賓丨張成】：由於咱們如今招聘的項目開始了，招聘的項目業務相對複雜，倒不是特別複雜，流程可能相對會比較多一些。對於業務的服務的變動要求可能會必須多一點。因此在中期的時候咱們就把整個技術站切到了微服務的架構裏面。可是實際上咱們在開展微服務的時候確實遇到了不少的問題，由於其實業務相關比較重，有不少的點不是太好去弄。咱們如今裏面ES其實用的會比較多，這個咱們後面能夠展開說爲何這個東西用得比較重，這是中間的權衡，不得已的選擇。

咱們微服務主要用到實際上是GRPC做爲整個基礎服務的框架，咱們服務的註冊發現是咱們本身開發的，自研的一個動態的NDS，而後經過內部的運營發現這個服務。服務追蹤的系統直接用的開源的zipkin，直接就跑在這個環境。如今整個看起來效果仍是蠻不錯的。

微服務真的要跑好很重要的一點就是自動化的程度，部署運維自動化的水平，這個地方我以爲咱們團隊作得仍是蠻好的。這套也是咱們本身開發的系統，基於mesos加上docker作的，整個如今開發運維徹底是自動化在作。還有一些相關的像錯誤日誌收集咱們用的sentry。還有很重要的一塊就是API Gateway這塊，咱們開始的時候也調研了不少，像Kong相關的一些。可是其實咱們在實際當中用的時候很難知足咱們實際的需求，因此在相對早的時候咱們就選擇本身開發這個API的Gateway。大概的狀況就是這樣。

【主持人丨大師兄】：張成，由於你以前也提過你多是對微服務有一些槽點，你能夠講一下。

【嘉賓丨張成】：不知道你們有沒有印象，微服務最先火的時候不少人以爲這個東西特別好，特別靈活，一我的能夠管理不少的微服務。其實微服務的關鍵一點就是這個微，小到底有多小？最關鍵就是在這個劃分上面。這裏面像以前我看過一篇文章說搞機器學習，提供機器學習的微服務有多好。這個其實沒有什麼可講的，由於微服務機器學習的一個接口就是一個接口，業務相關性真的很弱。可是實際上咱們在作一些業務相關性偏重的時候的系統其實這個劃分真的很難受，由於整個前端的數據上的需求會使得你後面的服務或多或少會有一些耦合，你怎麼下降這些耦合，怎麼把這個東西拆開，因此我以爲這是一個點最大的地方，真的是可能沒有你們想象的那麼好，說微服務這個東西用到以後真的就是怎麼樣這種，有不少點要去作。像剛剛講的自動化這點，若是真的地方作得相對差一點的話整個微服務是作不起來的。

還有就是整個對於業務上面劃分的點，這個可能真的是要具體問題具體講，真的不是太好說我有一個什麼樣的通用的方法，會有一個什麼樣的劃分的策略。

【主持人丨大師兄】：謝謝張成。接下去東昇你這邊介紹一下吧。

【嘉賓丨謝東昇】：你們好，我能夠簡單介紹一下我我的的微服務經歷，至今差很少四年的時間，前先後後三家公司，最開始的時候我接觸微服務是從dubbo開始的，你們問我爲何當時要去選擇dubbo呢？其實頗有趣的事當時咱們在順豐的時候，正好有兩位dubbo的框架的做者跟我一塊兒，dubbo就是他們本身作的，因此咱們組成一個團隊作事情的話會用咱們最熟悉的東西，就用dubbo。固然還有其餘緣由，那個時候Spring Cloud，也不像如今這麼完備火熱。當時用dubbo真正開始接觸微服務這件事情。

可是在作的時候，其實坦白說，包括如今你們來看dubbo，就會發現dubbo雖然已經很健全了，可是實際上也是須要一些配套的工做。必須咱們當時真正在作的時候會用兩塊東西，確定一個是服務的發現，服務發現咱們當時用的Zookeeper，相信不少公司都是這樣作的。還有就是配置的管理，咱們也是用的阿里的一個開源框架，叫Diamond，我相信不少朋友也都聽過的，這也是一個配套的東西。

當時咱們在dubbo的基礎上把咱們整個電商業務開展起來了。只能說當時從電商的角度看咱們來開展這個東西其實也仍是比較好劃分的，這個後面能夠多講，我先簡單說兩句。好比咱們按照用戶系統、產品系統、訂單系統，包括積分、優惠券，包括消息，包括短信相關的仍是比較好劃分的，咱們就基本上按照這個思路把一個模塊板創建起來了。可是我以爲確定這個過程當中，剛纔開始張成也提到了，這個過程當中會有痛點，痛點在於你一開始沒有一個全鏈路的監控，全鏈路監控就在於你有各類服務，你剛開始作的時候沒有這個東西，若是忽然出問題了，由於整個業務可能跨三個不一樣的服務，那你就不知道到底這個問題出在什麼地方。或者你這個請求特別慢，可能也是跨三到四個服務。究竟是哪一個環節出問題，哪一個服務致使整個請求，好比說要四秒鐘、五秒鐘，當時就很困難，確定要一個個去排查，去找。這是我以爲當時微服務的一個痛點，或者咱們能夠去吐槽的地方。後面咱們才逐步把它創建起來的，就是全鏈路的監控。

另一個事我能夠講一講，剛剛張成也提到一個網關的事情，其實dubbo本身能夠有一些網關的東西，可是實際上很弱。因此網關也是咱們當時一個很資深的同事去作的網關，徹底本身開發了一個網關的模塊。主要作什麼事情呢？第一就是協議的轉換，由於你可能對外到你的前端，你找HTTP或者HTTPS，你到內部網關內部確定是走的dubbo協議，這是一塊。

第二塊事情就是一些協議的分裝，好比你可能有一些安全或者是一些在業務這一層以外確定有系統層的一些編碼，這個有協議的封裝和相對於說解包和組裝的過程，固然可能還有一些安全性的東西，這是網關這塊。

除此以外我再簡單說一下，可能咱們當時在順豐作的時候其實虛擬化這塊用的比較淺，咱們當時直接是用Docker的，就沒有用如今例如Mesos這些東西其實當時尚未用到，咱們當時基本上是這樣的狀況。

我再講第二家公司，第二家公司狀況不太同樣，第二家公司咱們以前是All-in-One的狀況，自己有代碼作好了，可能就是一個war包部署在一塊兒，咱們可能相對說是怎麼把這個拆分它，這個咱們當時也是有一個過程。我也不詳細展開了，由於後面還會有一些互動的環節。如今咱們可能就是相比前兩家公司複雜一點，由於咱們這裏用到兩套，這個也是歷史緣由。咱們又用了dubbo的集羣，咱們有些服務是用dubbo來作好的，可是咱們有一些是用Spring Boot來作好的，固然咱們本身開發了一個ESB，以前經過ESB來註冊和發現暴露咱們的服務接口，而後造成一個混搭的局面。

可是其實也面臨很大的問題，因此咱們這個時候引入了一些好比說Zipkin這樣的東西來幫助咱們去全鏈路監控相關的一些東西。大概狀況就是這些。謝謝！

【主持人丨大師兄】：東昇，想問一下，由於你剛剛提到網關主要是用來區分不一樣的協議，那網關是否還有監控，過濾，頻控，降級方面的只能，並根據相關狀況從新路由請求？

【嘉賓丨謝東昇】：對，確實。至關於怎麼樣的一個狀況呢？其實關於服務降級這塊分爲多個層次，咱們由於在網關以外咱們還會有前置的Tengine(淘寶基於Nginx的開發), Tengine其實在必定程度上已經在幫咱們作一些降級的動做，好比咱們直接在分發請求的時候已經把接口直接返回，好比說返回一個錯誤碼，好比404也就直接返回了，就根據不會進入咱們的系統裏面去。固然咱們網關自己也會有這樣的東西，好比某個服務自己已經超負荷去運轉了，咱們會返回一些默認值，告訴他如今多是一個什麼樣的靜態的頁面，會有一個default的結果返回，這也是一種服務降級的策略。

除此以外，咱們後續引入了熔斷功能，降級和熔斷在我看來是不同的概念。咱們會有熔斷，但當時沒有徹底自行的開發，咱們是使用了Spring Cloud出來以後整合了一個框架，叫Spring HyStrix，引用了HyStrix裏面一些熔斷的機制整合到咱們系統當中去。

【主持人丨大師兄】：謝謝東昇。葛俊你來介紹一下吧。

【嘉賓丨葛俊】：那我簡單講一下以前在公司的操做，主要有三個公司跟微服務有點相關，因此我體會還蠻深的，每一個公司用的方式不同。首先徹底是沒有用微服務的一個公司是我在舊金山的一個小公司，徹底是用Monolithic的方式。Facebook使用的是混合式的，由於一開始Facebook是沒有用微服務，可是它也會有一些小的服務，逐漸須要開發和分離出來，就天然而然的引入了一些微服務的特色，沒有爲了要微服務而微服務，而是有這個須要就逐漸引入一些微服務的東西。Facebook有一個很大的代碼倉，全部的服務還有網站都在裏面，包括facebook.com，還有Facebook的API，很是多的服務都在上面。同時也有一些較爲獨立的服務在另外的代碼倉裏，客戶端經過前面提到的超大代碼倉來訪問這些單獨的服務。超大代碼倉在這裏有API GateWay的功能。這就是我前面提到的「混合型」的意思。

也就是說Facebook的結構徹底是一個逐步發展，從一個原來一大坨的那種單體架構，逐步發展到會有一些微服務的概念加進來。效果還挺好的，待會兒咱們討論槽點的時候能夠跟你們多講一些。

第三個公司是我在上海的一家創業公司，我去那邊作CTO的時候，我去的時候他們已經作了一年了。他們是使用徹底的微服務，是使用Kubernetes來搞的，全套使用K8s，效果還不錯。哪一個公司微服務的使用踩到一些大坑，很是痛苦。個人體驗是，不是微服務你也能夠用得很好，像Facebook。若是純是微服務你也能夠弄得好。可是都須要很當心，不然很痛苦。

【主持人丨大師兄】：接下來一個環節，由於你們也談了一下各自在各自公司的關於微服務的一些時間和經驗。以前剛剛嘉賓也提到主要有兩點，一個是關於服務劃分，如何劃分比較好，如何能解耦這是一個比較重要的方面。還有一個就是以前張成也提到的，沒有真正把微服務作到十分高效，可以把整個研發的精力給節約出來的話，自動化是比較關鍵的。因此，在第二階段咱們就準備了一些主題，針對每個主題和各位嘉賓進行一些探討。

第一個主題，實際上對於微服務，就像張成剛剛說到的，須要有一些自動化的東西，也就是微服務會有一些具體的帶來的關注點。其中包括中心化的一些配置管理，包括服務發現，包括怎麼作容錯，包括網關，包括一箇中心化的日誌服務，還有分佈式的監測系統，這些全部的關注點。可是我相信你們剛剛開始作微服務改造的時候是不可能計劃好把全部的東西和全部的關注點都上的。

第一個問題就在於若是要把如今的單體應用改形成微服務的話，你們以爲咱們應用去先上什麼？後上什麼？各位嘉賓誰能夠談一下本身的見解？

【嘉賓丨謝東昇】：我先講講我我的的觀點，簡單溝通一下。剛剛其實申竣也講了一下，說白了資源老是有限的，不可能一上來都是都關注到的，我們一開始都是一個很完備、很完美的微服務的體系，或者說從常規來講確定是分階段來作。對於這個問題我談談我過去幾年經驗的感覺。我先劃分一下階段，我劃爲四個階段，第一個階段是起步階段，就是咱們開始準備作微服務了，咱們必定要考慮什麼。第二階段是發展階段，也就是有必定經驗的。第三個階段是規模化階段，我基本對這塊已經有必定認識了，微服務已經在我線上跑得不錯了。第四塊就是隨着業務的發展已經很大了，大規模的微服務的階段。因此簡單劃爲四個階段，起步、發展、規模化和大規模化。

對於這四個階段我講講可能每一個階段要關注的點，第一個階段就是起步階段，起步階段我分爲四塊。第一個階段前面嘉賓也講了，就是一個自動化的部署，是我很在意的。由於你服務拆分了，你可能不少時候，那時候你不是簡單發佈一個哇包了，可能要發佈不少個包。那你必定要自動化，這樣才能保證你的效率也能提高，人力才能解放出來，還保證不會出錯。

第二塊就是咱們的基礎設施的自動化，好比微服務拆分，分佈這個擴容要分機器，我也是但願整個流程是自動化的。我不能說我去初始化一個環境，無論是虛擬機仍是個人容器我都由人工來作，不可能。第二塊就是基礎設施的自動化。

第三塊就是基本的監控報警，你這個報警是要有的。

第四塊就是日誌管理，必須必要的日誌要創建起來，這是我以爲我對起步階段在意的幾件事情。

接下來說講發展階段，發展階段會考慮更多，好比我會說一個發佈板塊的管理，由於你作了必定階段你版本必需要管理好，你怎麼來管理你的版本？第二塊是你的配置，你作到後面你的配置愈來愈多，好比咱們以前提到過用Diamond來管理動態配置和靜態配置。還有一塊就是服務的治理，就是依賴管理你是必需要明確的。由於那時候你微服務可能有十幾二十個服務了，他們之間的調用關係你必需要搞明白。最後一塊就是服務發現和負載均衡的。用的過程當中哪些服務平時壓力比較大，你是怎麼來管理它和擴容的，這塊事情。這是我以爲在發展階段關注的幾件事情。

最後講一下規模，我作到必定階段上規模了，比較多的可能就是灰度發佈，這個時候你相對來講每一個服務的機器已經不止一臺了，我可能不是單點，我可能每一個服務都有兩到三臺，如今是更多的集羣。灰度發佈我以爲是必需要創建起來的。還有一塊就是剛剛講到的服務降級和熔斷，甚至是一些過載保護，這是一塊。第三塊可能就是說由於你的服務愈來愈大，原來你沒有考慮曲理化，或者你沒有考慮一個PaaS的系統，可能如今你要考慮一個PaaS的系統，可能就是一個雲服務平臺或者什麼平臺必需要有了。

最後再講一下大規模階段，可能我剛剛提到的一個全鏈路的監控是必需要有的。你對每一個請求從你的前端到最終數據庫返回，總體每一個環節必需要有監控的手段把它看起來。第二塊就是一些安全的東西，安全的手段怎麼去保護。最後就是集羣管理，這個時候，在大一點的公司，須要考慮創建一些容災的設施，你是否是有南北機房，你是否是有多活，我以爲這個是在大規模階段在微服務體系下要考慮的問題。我簡單就說這些。謝謝！

【嘉賓丨葛俊】：這個問題是怎麼樣從一個大的單體轉到微服務是嗎？

【主持人丨大師兄】：對，可能我有須要東西都要作，有許多微服務的東西都要上，那我用怎麼樣的順序分別作這個事情。

【嘉賓丨葛俊】：這個事情我是這樣看的，首先每一個公司有各自不一樣的特性，我在Facebook學到最有感觸的一點是他們特別實用主義。所有都是根據實際的狀況。因此這個問題具體來說，個人感受是首先看一下我是否是須要微服務，若是須要微服務的話，哪些東西最能從爲服務化中獲益。好比說某一個模塊常常出問題，或者是容易變更，你就能夠考慮把這部分單獨寫成一個微服務。我以爲第一步多是先寫一個Gateway，完成對request進行轉發的能力，而後開始把剛纔講的變化比較多的那一塊挪出來。request一開始仍是指向單體結構，能分離成熟以後在進行轉發。

另一個選擇分離的模塊的方式是選擇一個依賴不太多的，容易上手的，把它先剝離出來。

這樣逐步把單體裏面一個個適合劃分紅微服務的劃分出來，單體裏面的這一部分代碼就逐步deprecated。經過這樣的方式逐漸地把單體應用逐漸微服務化。

中間有一步特別要注意的是服務怎麼拆分實現最合理的模塊化，這個是很是重要的一點，也是比較難的一點。

【嘉賓丨張成】：其實是這樣的，由於這兩三年一直在作招聘相關的業務系統，有點被業務系統傷到了，我就從業務的角度去講這件事情。可能有兩種開始，一種是開始的時候你們都在想微服務這個事情很美好，而後開始的時候都在作這件事情。個人建議是千萬不要開始就作這件事情，這件事情會嚴重影響起步的效率，由於你要作的東西真的太多了。就像好比自動化部署運維這件事情，其實作起來沒有那麼容易的，你真正能夠達到一個很靈活的部分服務的上線，包括後面相關的措施，其實不是太容易。

一般來說早期，咱們的需求量都會是一個單體的，由於它也能撐至關一段時間。可是當你的業務量上來以後，整個業務模塊，其實你單體裏面也要劃分業務模塊的。當你業務模塊劃分，當你整個單體支撐的服務有一些失利了，你服務上線的節奏，包括你有一些需求中間的一些修改可能跟不上節奏的時候就須要去拆。實際上這個時候的拆我以爲還不是微服務，其實拆有兩個層面的拆，一個是通用的基礎的模塊。通常來說咱們系統裏面都會有字典的服務，其實這種跟業務不相關的通用的小模塊。還有業務模塊上的帳號，或者是各個業務系統有各個系統的業務模塊。這種實際上咱們說得粗暴一點，你甚至能夠幾個模塊前面架一個Nginx也能夠作得很好，可是這個仍是跟着業務的規模和業務的量來走，後面仍是會有過渡到微服務的階段。

其實微服務的階段我理解的時候也是一個業務模塊上的劃分，粒度上，大小上的。就是把整個系統負載壓力整個分散開，使得某一個模塊的複用程度更高一點。在個人理解裏面本質上仍是這樣的想法，只是後面咱們有了不少的工具讓這些事情變得更好地運維，更好地跟蹤，更好地發現裏面的問題。因此我以爲作微服務關鍵的點仍是在於對於業務系統的理解上面。咱們的業務場景有不少，其實你這樣能不能拆，這個地方能不能拆，咱們拆到什麼樣的度，可能這樣的路子會更好一點。經過這樣的點的思考過渡到我用一些什麼樣的技術，我要自研的Gateway，仍是用一個什麼樣的Gateway，或者是其餘的一些。我是這樣看的。

【嘉賓丨葛俊】：我稍微補充一點，若是你這個單體應用很大了，這個時候比較重要的須要權衡時候是又來了一個新的服務。這個時候要考慮我值不值得多花一點時間把這個新的服務作成拆開的服務了。由於通常來講把它擺到單體的服務裏面花的時間會比較少，可是考慮中長期收益的話會是微服務化較好。這個時候你就須要要作判斷。

就像剛纔前面的嘉賓說的要根據實際狀況，若是新的業務來的時候是一個比較合適的時候，就把新的業務加到到舊的單體結構裏面去。

【主持人丨大師兄】：因此你的觀點是直接改造新的服務比處理歷史遺留問題是更合適的機會？

【嘉賓丨葛俊】：對，由於新的東西來的話是一個比較容易開始的時機。拆分已有服務主要好處主要是穩定性、可維護性這些東西。可是作新的東西時你原本要作一些跟設置相關的東西，因此這是比較好的時機去引入微服務。並且當你以爲單體比較大了，就不要再往裏面加了東西了。

【嘉賓丨張成】：我以爲剛剛葛俊說得很好，很實在。其實拆的點真的有幾類，像我剛剛講了有一個通用的模塊是一個很好的拆的點。可是新的這些業務小的點，新的模塊也是拆的點。還有一些點多是這樣的，咱們某一些模塊可能壓力確實太大，你跟整個的模塊放到一塊的話，咱們資源配備上會很是浪費，就很是有必要把這樣的點及時拆出來，若是它多作一些負載可能壓力總體能夠撐起來，可是資源的耗費可能比較小。

【主持人丨大師兄】：謝謝張成。正好張成這邊提到，包括葛俊後面提到服務的拆分。我這邊準備的第二個主題也是跟服務拆分相關的，張成剛剛提到從技術層面上的拆分，就是拆分一些通用的模塊，你們比較好理解。可是一開始你們介紹的時候可能對業務上的拆分，不一樣的嘉賓也有不一樣的一些理解，東昇在介紹的時候就提到由於電商系統可能相對來講業務比較成熟，因此我用戶模塊、訂單模塊是比較好地拆分出來的。張成在提到的時候可能市場上沒有比較成熟的專門作線上招聘的產品，因此這個時候業務拆分可能比較有講究，不是那麼好拆。我想你先談一下，能不能舉一些具體的例子，哪些業務上，你在作業務拆分的時候遇到過一些具體的問題，這可能不是一個特別好的拆分。若是比較好的拆分能夠達到一個什麼樣的效果，有沒有什麼最佳實踐或者基本的原則呢？

【嘉賓丨張成】：這個是能夠聊一下的，可能你們接觸到作招聘的互聯網團隊可能稍微少一點，後面有一些點能夠再交流。這裏面也不能說好的實踐，我其實如今真的對微服務滿腹怨言，由於我以爲前期你們提到的好多點，包括好多的技術文章真的誤導了不少後來的人，它的不少的點。我以前寫過一篇文章，叫看上去很美，確實看上去很美，可是咱們實際操做的時候確實有不少點。不敢說最佳實踐。

比方說我舉一個點，咱們在招聘裏面，其實招聘裏面咱們一般來說主體有候選人，有公司，還有一個就是咱們所說的JD，可能還有一些相關的人，像獵頭，像企業的HR，這樣一些實體。可是這裏面就會有一些很強的關聯，這些實體之間的關聯很是強，你若是按照以實體爲主的業務模塊去拆的時候。實際上咱們到最終如今的階段，咱們獲得一個結論，確實是這樣拆是能夠的，可是中間確實會有一些波折。比方最先的時候，像一個候選人有簡歷，他的履歷，履歷裏面有公司。最先比方一個獵頭也有履歷，履歷裏面也有公司，獵頭所屬的公司，企業HR所屬的公司，最開始的時候咱們就把人和公司這樣的一些實體，他們提供的一些服務就放到一塊兒去了。爲何放到一塊兒去？至關於早期的時候，固然在開發的時候也要兼顧一些效率。我說得土一點，咱們在查詢的時候，寫一些SQL，可能完成的事情不想去調整，調起來也不是很方便，可能也有一些性能上兼顧的考慮。可是實際上作着作着你就會發現，由於公司這個模塊在系統裏面承擔的角色不只僅是說我獵頭的所屬公司，或者是HR的所屬公司，還有一些其餘的角色。比方說候選人的工做履歷，還有一些其餘的應用。

這個時候你若是仍是跟獵頭或者HR的服務放到一塊的時候，帶來的弊端就會更大一些。比方我仍是須要去兩個業務的模塊混在一塊，我部署在一塊部署，升級的時候也在一塊升級，兩個一塊兒去作。後面咱們慢慢作的時候就意識到這個東西仍是要分開。就像公共基礎服務，其實咱們最終作的時候慢慢就會發現其實咱們的微服務。剛剛有一位專家也講過，其實有一個服務之間關係的問題。你要搞清楚這個服務之間的關係，我是否是太建議這個服務之間的關係，可能線有比較亂的。其實咱們最終慢慢去過渡，慢慢去進化的時候，其實服務之間有一個很明顯的層出來。最底下是很基礎的服務，像我以前提到的字典的服務，上面多是實體爲主的業務模塊的服務。這些層會很明顯地出來，這樣一些服務在複用性上面就會很高。中間也是改了幾回，而後拆了一下，又分開，分開以後又以爲作起來很不方便。

其實微服務在團隊裏面推的時候也挺麻煩的，工程師都以爲很麻煩，由於我一個SQL就能搞定的事情，爲何要劃服務？你劃服務以後要在Gateway裏面作聚合。原本一我的能夠作好的事情，如今要三我的去協做。這裏面確實會有一些推進上面的問題，可是實際上帶來的好處是很大的。我後面來了新的人，咱們在部署的時候我要針對這個模塊有單獨的點擊上線的內容，對整個系統的影響很是大，整個上線的節奏很是快，效率很是高。

其實咱們作業務系統的時候你們都有這個感覺，像咱們這種列表聚合類的查詢很是多，各類各樣的人才的列表，各類各樣的公司的列表，各類各樣的職位的列表，其實這些列表聚合過來其實都是從各個服務聚合過來的。按照咱們傳統的思路，其實這個東西若是用單體裏面SQL的話其實很是簡單，可是若是你經過服務的話你就要依賴多個服務，你這裏面有一些好比說排錯也很差排這樣的一些東西。這個裏面其實很重要的一點就是平衡，你這樣一個架構是想要一個什麼樣的目標，你是想去開發，是開發很簡單，仍是我後續整個的維護，整個的進化，整個業務迭代的節奏支持的更好呢？我以爲這個更可能是一個權衡吧。可是中間確實會有一些糾結，不少看上去很美好的東西中間真的是挺苦的，表面上看起來很光鮮。

【主持人丨大師兄】：謝謝張成，我聽下來可能只有你們通過一些經過的經歷以後可能纔會意識到一些可能有些東西確實是須要作微服務。其餘嘉賓有一些關於這點有什麼想說的嗎？

【嘉賓丨謝東昇】：關於拆分的事簡單談談個人見解。我以爲具體來講無論我按照什麼方式來猜，可是有一些基本的東西咱們能夠提煉出來的。好比第一點，服務之間是獨立的，必定是拆分之後好比說拆成兩個，原來是一個，如今拆成A和B。我以爲第二個原則就是你服務之間是低耦合的，若是你拆出來兩個服務間仍是耦合比較重，那說明這樣的拆分的方式自己就是錯的。

第二點，每一個服務自己是能夠獨立測試的。意思就是說我這個服務拆分出來，我要去驗證它，我不會說我要依賴另外的服務我這個才能夠驗證。這是一點。

還有一點就是你服務的力度，剛纔張成也說到了，我怎麼樣算一個服務力度比較合適呢？我以爲我表面的原則是你服務通常來講是能夠三我的左右，三個工程師左右，你能夠吃得下來，我以爲就比較好了。你拆得好比一我的就能夠維護，那也不行，要七八我的作也不太行。服務粒度我我的的把控是差很少三我的左右能夠來維護或者是來應對這個服務，我以爲粒度就差很少了。

【主持人丨大師兄】：你剛剛提到你爲何會以爲一我的用來維護可能不太合適？

【嘉賓丨謝東昇】：由於我以爲一我的的話說明這個服務自己就比較簡單，就是力度可能過於小了。可能每一個人公司的狀況不同，若是咱們不考慮人的資源的狀況下，我以爲通常是三我的左右。由於有兩個方面的考慮，第一，微服務是相對封閉的，裏面是是一條垂直的線，若是一我的維護有哪幾點很差？第一是力度過細，第二個是萬一這我的今天請假了或者是生病了，甚至離職了，那總要有一我的backup吧，通常來講我但願從團隊管理的角度來講三我的左右是比較合適的。

最後再補充兩句，拆分來講我是一個思路，咱們電商也好，互金領域也好，基本上好比互金領域，咱們基本的方式就是根據業務能力來拆分。好比剛剛提到訂單、客戶管理、產品，咱們都是按照這種方式來拆。可是實際上除此維度以外咱們還有一個概念，咱們會把服務劃爲三塊，哪三塊？可能就是一個基礎服務，它實際上是跟業務關係不大的，可能就是最基本的，可是多是提供一些基礎的東西的，或者叫通用服務。第二塊是一些基礎服務，好比第三方的一些東西，好比發短信、支付網關，可能跟我直接業務沒有關係了，可是是對個人業務有必定支持做用。第三塊就是核心業務了，核心業務好比個人審批流程，或者是風控，這是個人核心價值，那是一塊。我基本上是從這兩個角度來看，一個是業務，一個是領域，基本上是這麼一個事物。大概就說這些。

【嘉賓丨葛俊】：我再補充幾點。我想給你們分享一些使用微服務的很差的使用方式和運做方式。我在以前一家公司有很是深入的體會，因此我想跟你們分享一下，但願對你們有點幫助。第一個問題是拆分得太細。首先，那個公司作的業務是相似Facebook的一個大而全的社交App。支持發帖子、發照片、互相點贊，一句話就是跟Facebook差很少。那個公司開發的人就二十個，可是服務竟然有三十多個。拆分太細。就像剛纔你們提到的，一我的一個服務，甚至一我的三四個服務，這個狀況很是很差。我我的以爲像一個創業公司可能就二十我的的話，甚至都不適合用微服務。由於使用微服務的那些好處實際上你在比較小的團隊下，使用單體也是不太難作獲得的。而使用微服務的坑帶來的壞處很瘋狂。剛纔提到的那個公司，咱們一共就二十個開發人員，就有五種語言。微服務的一個好處不就是你想怎麼搞怎麼搞，怎麼快怎麼快來嗎？因此你們隨便搞，語言，框架就愈來愈雜。結果是你們根本就很難共享對方的技能，誰也不能出差，誰也不能生個病，你生病這個東西就完了。

另一個踩的坑是組織結構，這個公司的組織結構和微服務就不吻合。微服務比較好的組織結構是作一個服務的人在一塊兒作，前端和後端得人至少要在一個虛擬的組織裏面。而這個公司以前的安排是按傳統來劃分的，主要就四個大團隊，前端、後端和設計，還有一個產品。這樣致使的結果，就是在這麼小的公司就出現辦公室政治。我反正是作後端的人，負責個人獎金績效的是後端的主管，不跟個人業務強相關。並且問題仍是挺明顯的，就會致使運做起來很彆扭的。

有一個康威定律講的就是這個東西。就是若是你搞微服務的話你必定要讓每一個人員的績效跟他作的業務直接掛鉤。這是第二個坑。

第三個坑，他們對微服務的理解，理解得太過了。後端的各類服務全作成微服務，原子化。邏輯放到前端。後端的人認爲我就要把個人服務作好就好了。使用的細節是前端的事。這根剛纔提到的康威定律有關。最後就致使用戶一個操做須要發不少請求到服務器端，性能問題很大。這個問題一開始沒有暴露，由於在演示的時候用戶訪問量不大，可是上線以後很快就不行了。

還有一個坑是數據庫，有的地方有幾個服務會共享一個數據庫，這個是一個比較差的操做，應該各個服務儘可能本身搞本身的數據庫的。還有最後一個坑是關於部署的。每個服務應該單獨各自部署的。我本身一開始就犯了這個錯。

大概就是這幾個坑我深入體會到，因此但願給到你們，尤爲是作這種小公司的人一些啓發。

【主持人丨大師兄】：謝謝葛俊，葛俊主要問題是在兩點，第一點是雖然我這邊去拆分的微服務，可是有些東西可能我整個的研發管理或者技術管理有一些框架方面的東西，或者語言方面的東西仍是要作一些規範，防止打得太分散，很差管理。第二點，由於葛俊剛剛也提到整個的微服務這樣的開發實際上是和研發的一些組織結構、架構和技能要求是有關係的。

接下來我這邊想討論的主題就是在對整個的系統進行微服務化之後你帶來的整個的研發組織架構，包括技能要求是否是會有一些新的變動去適應整個的系統的微服務化。關於這點哪位嘉賓想先來聊一下。

【嘉賓丨謝東昇】：我先來簡單講一下，剛纔葛俊和張成講得很是好，我從個人角度補充一下。坦白說，其實你們作過老的那一套，好比說all-in-one的東西，包括如今微服務之後，我以爲會有一個比較深的感覺。好比咱們就講如今吧，如今其實我以爲最重要的一點咱們微服務之後，每一個服務無論幾我的，至少有一個工程師是這個服務的負責人，你必需要有這樣一我的的。不然的話，其實它是徹底你的模塊拆分好之後，必定是這我的要對這個模塊負責，你不能說他們都不對這個模塊負責，那無法作了。因此必定要有一個工程師對這個模塊負責，這是研發組織上最大的不同，必定是有負責人制的。不是說一個技術經理就解決的，必定是每一個模塊有本身的負責人。

第二點，真正執行微服務之後，正常的狀況就是其實他跟過去不太同樣，其實他們之間的交集會相對來講減小。可能這是咱們理想當中微服務的好處，這個微服務就是他們兩三我的作，其餘人也不關心了，他們把它作好就OK。可是其實實際上這樣作也會有問題，因此咱們按期仍是會有一些交流的，這也是咱們週會、晨會必需要的。而不是微服務之後你就本身悶頭去作，必定會有大問題的。必定是咱們按期經過晨會的形式，經過週會的形式，服務之間必定是有個交互的，就是說須要有一個溝通機制。

還有一塊我以爲很重要的一點是在於技能上面，剛剛提到每一個工程師的技能。從咱們最開始其實咱們的劃分技能是怎麼劃的？咱們就是前端負責作展現，中間層就作邏輯的，作Controller，作Service Bean的，後面數據庫，數據庫鏈接，作緩存相關的。咱們最初都是這樣劃分的，多是比較老的劃分方式，是水平切分，從前到後來切。可是你作微服務之後可能這個東西就不太同樣，相對來講你這個服務從前到後，從你的API，流轉到服務層，到緩存，到你的DB那確定都是你來負責。因此對於一個工程師來講他的技能不太同樣，就至關於像你們提到的全棧，我以爲有這個趨勢，至關於你這個技能從前到後必需要知道的。不止是說我只管好這一塊就OK了。我以爲對技能上面可能要求會更高，由於你還要對數據庫看，你還要緩存。不能說原來我無論，你這個緩存有問題，數據庫鏈接有問題，我無論，如今你必需要管，由於你必需要作好服務人。

最後說一點，我以爲實際上是整個微服務這塊很重要的一點就是咱們團隊工程師能力的提高。第二個就是自個人驅動力必需要更高，由於工程師要對這個服務負責。深刻了解業務的狀況，因此自驅力必需要提升。第二個就是學習能力要更強，由於工程師要對這個服務負責，你是要了解業務的。剛纔其實應該是葛俊講的，你跟他說我把後端作好就能夠了，那你必定是要對服務負責的。服務負責就是技術、業務你都要服務，那你的學習能力是很重要的一點。固然反過來講，這樣好的一點是你對他我的的成長打開了更大的空間。

再說兩句，這個時候其實還會有一些，好比你這個時候會有一個架構師，由於你這個團隊會有一個架構師的角色或者是技術經理的角色，我以爲整個團隊至關於變成了一個球隊，架構師和技術經理對應因而球隊主教練的角色。做爲主教練你怎麼讓這個陣型保持得很好，咱們球隊怎麼保持好陣型，這是我以爲架構師和技術經理必需要考慮的問題。一個球隊，分紅中場、前端或者是後衛，怎麼保持他們的陣型，中間的配合是否是足夠到位，傳球順不順，中場和前場會不會脫節等等，這都是技術管理者要解決的問題。 以上是我我的的一點感覺。差很少就說這些。謝謝！

【主持人丨大師兄】：謝謝東昇，這個問題其餘嘉賓還想發表其餘的見解嗎？

【嘉賓丨張成】：我補充一下，其實我這邊以爲仍是蠻簡單的，剛剛東昇講的也挺全面的。我簡單說一下我這邊的一些作法。我以爲有三點。第一點，實際上咱們Gateway這塊，咱們是本身研發的。咱們Gateway這個地方有一個單獨的組，我以爲這個事也是頗有必要的，整個微服務後端全部的服務跟前端如何打交道，如何統一協調，Gateway這個組其實很關鍵，從業務的角度來說。還有就是咱們實際上天天早上有一個站會，儘管是服務比較多了，可是這個站會必須舉行。由於你服務多了以後溝通上的成本是蠻高的，同步的風險是很大的。站會上很重要的一點就是各個服務之間同步。

還有一個就是其實對工程師我的技能的要求實際上是蠻高的，對於他們的成長空間，也給了他們一個比較大的成長空間。由於你至關因而獨立負責以後，直接從前到後，就至關於你的API也好，你的數據庫這些亂七八糟的東西你都要掌握，都要考慮，而不只僅是之前水平的劃分，對能力上要求可能稍微不是那麼強，如今要很全面。因此在招人上面也會有一些影響。

大概就是這三點，我以爲對於團隊組織結構上有這三點影響。

【主持人丨大師兄】：謝謝。咱們這邊時間差很少了，因此接下來的一些時間咱們就留給聽衆看一下他們有什麼問題想要問一下嘉賓。

【嘉賓丨葛俊】：如今他們問問題的時候我能夠補充一個東西，你們可能也聽得出來咱們對微服務採起的是比較謹慎的態度。之因此這樣作是由於我以前在一個的小公司作技術總監的時候，單體的應用作一個社交網絡App很是順利。 同事Facebook那麼大的比較單體結構框架下，Agile也可以作得很是好。Facebook能夠一個禮拜上線一次，而後天天還能夠上線兩次，若是有Hotfix半個小時也能夠上線。固然單體會有一些壞處，須要更多的隨時注意架構防腐化。因此，有好處，也有壞處。公司隊伍還比較小的時候我我的是比較傾向於不要使用微服務。

【主持人丨大師兄】：謝謝葛俊。剛剛我看到討論組裏面有人想讓嘉賓談一下關於虛擬化、容器化方面和微服務結合的技術。個人理解應該是是否須要立刻去作一些虛擬化和容器化，以及應該怎麼樣作，去結合微服務的哪個點。

【嘉賓丨謝東昇】：我簡單說一下吧，由於這個我不敢說很資深，可是我能夠講一下我我的的感覺。坦白說，我以爲微服務和容器化之間沒有一一對應或者強關聯的。你要不要作微服務和要不要容器化實際上是沒有直接關係的，你能夠單體同樣用微服務，沒有任何關係。我認爲是看所在的階段，在我看來，其實以前葛俊講得很好。說實話，看你團隊的一個階段，單純的說你即使微服務要不要都是一個問題，其實虛擬化也是這樣的，你把虛擬化的技術引進來必定也會考慮到資源的一些整合。若是你的資源自己很充足，其實我也不缺機器了，我無論虛擬機也好，硬件設備也好，IDC機房這些東西我以爲都夠用了，那我以爲不必去搞虛擬化這些東西，這是大白話了，我真的以爲不必。

除非說我如今已經到了必定規模了，我已是一個很大的互聯網公司了，個人產品服務至少是幾百萬用戶了，我以爲你能夠考慮一些虛擬化的東西，這個能夠幫助我在部署和資源的整合確實能夠帶來一些實實在在很大的一些經濟上，成本上的好處。不然我以爲虛擬化咱們本身也在用。可是有的時候也有不少坑，無論是容器，仍是以前Virtual Machine，他們雖然如今已經發展得很成熟了，可是你引入新的技術站進來，必定會帶來一些潛在的一些問題。因此我認爲仍是要看階段的。我不認爲任何一個，特別是初創公司，一上來就要去考慮虛擬化，考慮微服務我真的不贊同。除非我公司到了必定規模了，我想考慮這些東西了我再來講。這是我我的的觀點。

簡單來講，好比我如今作微服務，我如今好比有dubbo這條線，我有Spring Cloud這條線，我究竟是用Spring Cloud，仍是用dubbo呢？我談談我我的的觀點。我我的以爲若是你的團隊有一些二次開發的能力，或者你的知識儲備作得比較好的話，我以爲你能夠用dubbo。可是若是你自己團隊對於不少，好比說一些中間件的開發你其實沒有這個能力的話我仍是建議用Spring Cloud. 由於Spring Cloud其實已經提供了不少的組件了，好比相似於你服務網關有現成的東西，什麼斷路器、分佈式配置、服務跟蹤、消息總線這些東西（英）實際上已經有了，dubbo是沒有的，dubbo你要本身弄的。好比說註冊中心你起碼要把Zookeeper搞懂，好比你的分佈式配置起碼你有一套東西，好比你要跟阿里的Diamond結合起來。

因此我以爲若是你的團隊比較小，那你的團隊要專一業務開發的話，我是建議你們去多趨向於Spring Cloud，可是若是你的團隊其實在中間件相關的東西，這塊有人力有研究，我以爲你能夠用dubbo。我本身用dubbo，可是說實話用dubbo你須要必定的二次開發的東西。

【嘉賓丨葛俊】：剛纔東昇提到的關於虛擬化、容器化這些東西我稍微補充一點。個人經驗裏面用虛擬化和容器化開發起來很是少，原來在AWS上面開發的話就比較容易，用虛擬化和容器很是容易自動化。開發人員平時想試個什麼東西都很是方便。

舉一個例子，在Linux上裝一些軟件很煩人。一個例子是Samba。曾經有一次更新花了我四個小時！可是我最近開始使用容器來解決一些軟件安裝問題。我如今直接運行一個Samba容器。有新版本以後就更新容器。好方便。雖然我對Linux還算比較熟悉，可是裝軟件這個東西有時候會很噁心。容器幫了我很大的忙。個人我的體驗是用Virtual Machine，Container對平時的開發很方便，即便你不用他來搞生產環境。

還有一個，K8s我以爲如今也比較成熟了。它順帶的一堆服務很方便。若是你們在開始使用微服務的話能夠考慮使用它。

【嘉賓丨謝東昇】：我再補充一下。剛纔葛俊說的，我以爲是這樣的，剛纔的話題我再簡單補充一下。坦白說，我以爲虛擬化有兩塊，一塊是Virual Machine，第二塊就是自己我這個容器，好比Docker這樣的容器。從個人感覺，由於我是比較趨向於如今把VM 先用好，在一開始。不是說我排斥容器這個事情，可能關鍵時候我堅持，若是咱們要作虛擬化，好比咱們如今公司也用雲的產品。我是認爲先把VM這塊東西用好之後我再去考慮更進一步的去容器化這個東西。這是我我的的感覺我不但願一上來直接跳過虛擬機，直接上來，我就是要先容器化這個東西，我剛纔的觀點是這塊。可是我以爲你把虛擬機用到必定程度之後，說這塊東西我掌握得差很少，我吃透了，我再來遞進到容器這塊，從我我的感覺來講你會少踩一些坑。

【嘉賓丨葛俊】：這點我很是贊同。這種按部就班不是爲了容器化和容器化，而是漸進的，我真的須要它，把它吃透了。這點我很是贊同。

【主持人丨大師兄】：謝謝兩位嘉賓。由於此次的主題是微服務，若是你們以後想更關注虛擬化關於容器化的主題的話，會單獨再開展。今天針對這個話題就再也不深刻了。若是你們沒有什麼想補充的話咱們今天就先到這裏了。謝謝三位嘉賓！

「跨境茶話會」是由移動增加技術服務商「魔窗」聯合國內外衆多技術專家發起的在線技術交流活動，目前已邀請嘉賓來自Google、ebay、Snap、Uber、VISA、Pinterest、BranchMeteics、Splunk、小紅書、華爲等國際知名IT企業在職高級工程師，面向全部互聯網從業技術人員分享交流先進理念和實戰案例，同時爲中美技術朋友提供跨境交友和深度學習的平臺。

「跨境茶話會」結合前沿熱點技術話題，精心策劃每個月一個線上技術主題交流，每期邀請來自國內外互聯網界的三位實戰嘉賓分享一線技術最佳實踐，並針對核心技術問題對話答疑，爲技術從業者拓寬思路、提高技術實力、驅動業務增加。

下期免費報名：https://www.wenjuan.net/s/3iu...