參加Dubbo社區開發者日成都站後，帶給個人一點思考。

本文首發於公衆號，關注文末公衆號，閱讀體驗更佳。

2019年Dubbo社區開發者日成都站一共有七位老師進行了分享。你想要了解他們都分享了些啥嗎？

個人收穫

進入會場的時候能夠在接待臺的地方拿到七個摺頁，每個摺頁都是阿里對開源社區的共享，每個摺頁的背後都表明着一個團隊的辛勤付出，他們爲中國在世界的開源史上落下了濃墨重彩的一筆。值得尊重，我也必須一一打出來，以示尊重。它們分別是: 【Dubbo】國內最受歡迎的服務框架、服務化/微服務最佳解決方案。 【阿里巴巴Spring Cloud】微服務開發一站式解決方案。 【Nacos】一個更易於構建元原生應用的動態服務發現配置管理和服務管理平臺。 【ChaosBlade】阿里巴巴開源的一款簡單易用、功能強大的混沌實驗注入工具。 【Alibaba Java】應用診斷利器。 【Dragonfly】元原生的鏡像與文件分發解決方案。 【Sentinel】The Flow Sentinel of your Microservices

此次成都的Dubbo社區開發者日宣傳海報上一共有六個議題.

可是實際上來分享的老師有七位。

在活動開始以前還有一個暖場的小活動。就是作一個簡單的自我介紹，而後介紹的比較好的，阿里的小姐姐會送一本小馬哥寫的《SprintBoot編程思想》，仍是簽名版哦。

這環節是個人強項啊。因此，當仁不讓，我有幸得到了這個獎品。謝謝小姐姐，謝謝小馬哥。

同時，在自我介紹的環節，我驚奇的發現，我旁邊的這個哥們，竟然閱讀過個人公衆號文章。在會議進行的過程當中，我更加驚奇的發現，我右前方的哥們也讀過我公衆號的文章。

這就很神奇了。

微服務轉型

在這七個優秀的分享中，每個均可以拿出來單獨寫一篇文章，若是一篇文章包含了全部的分享，那大機率是泛泛而談了。

我不想泛泛而談，因此在這篇文章裏我只寫一個主題：來自新網銀行謝延澤老師的分享。

謝老師分享主題是《新網銀行微服務轉型實踐》，主要是關於微服務落地的相關內容。我會結合謝老師的PPT來分享一下個人一些思考。

Part 1 新網銀行簡介

謝老師的第一部分分享的內容是新網銀行的簡介。我截取其中表現數據的PPT給你們分享一下,畢竟你們都是對數據、對流量比較感興趣的。

新網銀行的大三股東分別是:新但願集團、小米、紅旗連鎖。於2016年創辦，到如今不到3年的時間。

新網銀行是一家互聯網銀行。

中國傳統銀行，好比四大行：中國工商銀行、中國農業銀行、中國銀行、中國建設銀行。你能夠在全國各地看到他們的分支機構，每一個分支機構裏面有若干個客戶經理再引導你作各類業務，其中一大業務就是存錢、取錢。

你在傳統銀行裏能看到的，在新網銀行都看不到。咱們沒有分支機構(強行說的話算是有一個，可是其做用主要是爲了展現品牌用)、沒有客戶經理、沒用現金業務。

在《銀行4.0》這本書裏面說到了:金融服務無處不在，就是不在銀行網點。

新網銀行徹底符合這句話。

可是符合這句話的，不只僅是新網，還有不少的互聯網巨頭金融板塊，好比阿里的網商銀行。網商銀行依附於阿里，有大量的原生客羣，阿里的app應用有豐富的支付場景，多種多樣的合法的可分析的特殊數據，好比用戶的購買記錄。

而這些，新網銀行都沒有。在什麼都沒有的狀況下，新網銀行做出了怎麼樣的選擇呢?

用技術鏈接了場景端和資金端。

那新網在這三年的發展中交出了什麼樣的答卷呢？

這些業務數據，不言而喻，能夠說是一份十分優秀的答卷。

全國第一家全在線實時全客羣的銀行。 全國第二家得到高新技術企業資格的民營銀行。（第一家是微衆銀行） 全國第三家得到銀監會線上信貸業務備案許可的銀行。(前兩家是微衆銀行、網商銀行)

Part 2 微服務簡介

對於微服務的定義，謝老師的PPT裏面是這樣描述的：

我以爲這個定義仍是很精準的。微服務是一種概念，一種實現方式，一種設計理念，而不是一種具體的技術。不是說你的項目中用了Dubbo、用了SpringCloud等等技術，這個服務就是微服務了。微服務徹底不侷限於框架或者語言。

我談一談我的對於第一段話的理解：

微服務是一種將一個單一應用程序開發爲一組小型服務的方法。每一個服務運行在本身的進程中，服務間通訊採用輕量級通訊機制 。

拿我參與過的一個項目來舉例。

上家公司是一家作支付的公司。支付有各類各樣的支付通道，咱們把這些支付通道聚合在了一塊兒，對外輸出的是統一且穩定的支付服務。可是這個支付服務背後，對應的是一個單體的大項目，全部人都在這個項目上進行開發。我所謂單體大項目的意思就是，用戶功能、支付功能、訂單功能、帳戶功能都在同一個應用裏面，不一樣組的開發人員都在這一個項目上進行開發。在這個場景下，隨着公司的快速發展，人員愈來愈多，項目變得十分臃腫，開發人員也不敢輕易動手開發，徹底談不上什麼架構思想、高耦合、低內聚。

公司及時的將這個單一應用程序，拆分爲了用戶服務、支付服務、訂單服務、帳戶服務。這個過程，就是服務拆分，微服務化的一個過程。每一個服務，都有本身的服務器，服務之間調用是採用的Dubbo框架。

在單一大項目中咱們能提供的服務，在拆分爲微服務後咱們一樣能夠提供，並且性能更好。

在上面的這個場景中，咱們拆分後的架構，就是由微服務組成的架構。以前的很長一段時間裏面，我理解的微服務就是支付服務、訂單服務、帳戶服務這一個個系統，可是這樣的理解是很片面的。**一個由Dubbo開發完成的服務不能叫微服務，只能叫作微服務中的一個部分。**別忘了，上面說的，服務之間還要通信。假設你只有一個支付服務，你和誰通信呢？那你能說這個支付服務是微服務嗎？很明顯不能的。

一個服務使用微服務架構的話，只有兩種可能性。

第一種是對原來大系統的拆分。 第二種是最開始就採用了微服務架構來設計。

我祝你碰見的都是第二種狀況。

微服務的起源，從PPT咱們能夠看出，2012年這個概念纔算出現，距離落地還有必定的距離，2014年纔算正式提出，2016年纔算是有了一個比較容易理解的明肯定義。從2014年到2016年，處於摸着石頭過河的階段。

微服務的優勢，邏輯清晰、簡化部署、可擴展、靈活組合、技術異構、故障隔離。

仍是拿我以前舉的列子，咱們來一個個的說。

邏輯清晰:支付服務只管對接支付通道，須要操做帳戶，對帳戶進行凍結、解凍、扣款的操做時，只須要調用帳戶服務提供的對應接口便可。簡而言之，帳戶的具體邏輯，對於支付服務是一個黑盒。支付服務只須要把更多的注意力放到自身的邏輯上便可。這樣，一個服務幹本身該乾的事。邏輯清晰。

簡化部署:當有新功能來臨時，若是通過需求拆分後，發現只須要修改支付服務便可。那咱們只須要修改並部署支付服務便可。若是不是微服務架構，你得整個項目從新部署，包括沒有改動的部分，這是咱們不但願看見的。

可擴展:這個沒啥說的了，微服務設計天生適合擴展。

靈活組合:每個系統，就是微服務的一個部分，當用戶系統、支付系統、訂單系統、帳戶系統組成一個微服務架構的時候，對外輸出的是商城能力，其使用方是C端用戶。當支付服務、訂單服務、清結算服務組成一個微服務架構的時候，對外輸出是支付能力，使用方是B端用戶。這就是靈活組合。

技術異構:只要兩個服務之間能接收而且正確的解析req/resp報文，那各自的服務可用不一樣的語言開發，使用不一樣的技術棧，使用不一樣的數據存儲技術。簡而言之，技術異構。

對於技術異構這一點，我想借用第二位分享者馬驥老師的PPT多說一句：

若是有技術異構，那大機率涉及到跨語言的需求。那在馬驥老師看來:

跨語言特性實際是RPC層的支持，本質是協議層面的支持。

你們能夠細細的品味一下這句話，一語中的。

故障隔離:因爲每一個服務都運行在本身的服務器中，首先服務器就是天生隔離的。其次，只要服務的調用方，作好服務容錯機制。當下遊服務出現異常的時候，對上游服務系統的運行不會產生影響。可是，對因而否會對業務產生影響，這個得結合業務進行分析。

這些優勢在各大會議上頻頻出現，因此謝老師只是走馬觀花的提了一下。重點想要說的是第三部分，帶來的挑戰。

Part 3 帶來的挑戰

帶來的挑戰，包括可是不限於下面列出的幾點。

對於帶來的挑戰，咱們也能夠一個個的來講。

可用率下降

首先第一個，怎麼去理解這個可用率下降呢？

當咱們對系統進行微服務設計後，勢必意味着須要更多的服務器和相關的基礎設施(諸如Nginx、redis、mysql等等)。好比下面的這兩個問題:

跨機房調用時涉及到防火牆問題。 因爲基礎設施的增多，基礎設施的不穩定，會帶來服務的不穩定。

在單體應用裏面則沒有這些考慮。從這個角度來講，服務的可用率下降了。

同時服務與服務之間須要進行跨進程的調用或者經過網絡進行調用。若是這些服務的功能仍是糅合在一個項目裏面，並不會帶來這樣的問題。因此，從跨進程或網絡調用的這個角度來講，服務的可用率是下降了。

因此咱們在設計微服務系統的時候，其中的一個重要的原則就是面向故障設計。必須對預知和不可預知的故障進行充分的分析。打好提早量，作好容錯機制。

事務複雜度

這個能夠說是家喻戶曉了，對吧。拆分服務後，你大機率會碰到分佈式事務的問題。

不要說你沒有碰到過，極有多是你碰到了，可是你不知道這就是分佈式事務。並且這種狀況，我猜大家大機率使用的是最終一致性的解決方案。

分佈式事務，又分爲兩種，一種是跨庫的分佈式事務，一種是跨服務的分佈式事務。

分佈式事務的解決方案也是多種多樣的，我我的認爲，每一種方案說到底不外乎兩種：最終一致性和強一致性。

好比咱們能夠基於本地表狀態查詢的方法、基於註冊回調接口的方法、基於消息隊列的方法、基於TCC分佈式事務的方法...

大多數場景，使用數據的最終一致性方案都是能夠知足的。可是好比在銀行的場景裏面，對於帳務的操做，必須是強一致性的。

對於分佈式事務，以前有公衆號讀者叫我寫一篇文章，可是這個確實是有不少人寫過了，並且有的文章很優質，我寫出來的不必定比他們好。因此對這塊有興趣的（能夠了解一下，分佈式事務，也算是面試常問的面試範圍）同窗，你能夠去翻翻其餘的文章。

巧合的是，在此次的分享中，最後一位分享的老師季敏(Seata 開源項目發起人)，他分享的主題就是《Seata 101》。Seata也是一種分佈式事務的解決方案。從git上看，其收到的關注度仍是比較高的。

貼兩張季敏老師的PPT給你們看看：

具體能夠去git上看看Seata的介紹，待我有了更加深刻的理解後，會輸出一篇相關的文章。

運維複雜度

上面的圖是某個單體應用徹底微服務化後的架構圖。

微服務化後的系統，勢必帶來的一個問題就是對於運維工做的複雜度。一個單體應用，咱們假拆分後有20個服務，每一個服務對應一個系統，每一個系統你要保證他的高可用，至少須要部署2個節點，這樣算下來就是至少40個節點。這裏我尚未假設其中的某個服務的訪問特別大，好比說是網關層，那部署的節點可能就不止2個了。

假設有一次這些服務所有都須要上線，若是大家沒有諸如k8s這樣的服務編排基礎設施，須要運維人員手動一個個的到服務器上去操做，好的，告辭。

因此謝老師給出的忠告是：在底層的基礎設施還不夠完善的時候，不要貿然去推微服務。

調優複雜度

分佈式鏈路追蹤工具

當咱們只是一個單體應用的時候，咱們也須要對用戶的請求進行調用鏈路的追蹤，可是不是分佈式的，這個功能很是好實現。

可是當咱們的系統微服務化後呢？可能當你的服務個數很少的時候，你還沒以爲調用鏈路追蹤的重要性，由於就那幾個服務，調用關係你爛熟於心。可是，當服務多到你都記不清的時候，分佈式調用鏈路追蹤的重要性就體現出來了。

我所知道的分佈式調用鏈路的實現方式有大衆點評開源的cat、twitter團隊開源 Zipkin、華爲開源的skywalking、naver團隊開源的pinpoint。

圖片來源:blog.csdn.net/u012394095/…

合理規範的日誌

日誌必須規範，接口的請求參數和輸出參數須要打印出來，之後"對簿公堂"的時候這就是證據。若是拿不出證據，這個鍋你就得背好。

同時，爲了方便不一樣系統之間的問題查詢，或者對日誌進行聚合分析，建議給日誌打上追蹤號。好比Dubbo filter+MDC技術，SpringCloud的sleuth，瞭解一下。

高性能的日誌平臺

不論你是使用很是成熟的ELK去聚合、分析大家的日誌，仍是其餘的日誌聚合技術。首要須要保證的一個點就是性能，就是響應速度。開發人員用你的日誌平臺就是爲了方便的查看日誌，可是點擊查詢後半天沒有反應，這誰受得了啊。等你反應過來了，我一臺臺服務器登陸上去查也查出來了，若是出現這樣的狀況，你能夠想象一下開發人員的心情。

測試複雜度

這一小節，我沒有什麼特別想說的，惟一想要強調的是：作好單元測試，作好單元測試，作好單元測試。

否則聯調的時候，對方會以爲你low，你會以爲對方很煩。

聚合查詢

這個得好好說說，這是一個大坑啊！痛點啊！

咱們拆分微服務的時候，是站在C端用戶的角度拆分的。假設咱們把服務拆成了用戶服務、訂單服務、支付服務、帳務服務。看着沒毛病啊，C端用戶用起來十分流暢，徹底感知不到你具體有哪些服務。

這個時候巧了，運營人員也徹底感知不到你有哪些服務。他們提出的需求怎麼說呢。是能夠理解的，可是站在開發的角度來講:

因此，在拆分微服務的時候，必定要把：有沒有、需不須要大數據平臺的支撐做爲一個重要的考量點。若是考慮不充分，當你碰到這些千奇百怪的需求時，你只能臨時拿出一個很是low、性能低下、實現起來很是難受的方案。

什麼？你說你不接這個需求？

Part 3 咱們的實踐

這一部分謝老師分享了兩個案例。

一個是成功的微服務化的過程，一個是過分設計帶來的問題。

成功的微服務化的過程

這是微服務化以前的系統架構。

通過按部就班、逐步拆分、由簡到繁、由粗到細這樣的一個實施過程後：

拆服務必定不是一個一蹴而就的過程，它必定是一個按部就班的過程。

通過拆分後，系統變成了這個樣子:

在這個過程當中，謝老師提到了拆分原則，對應的具體理論知識能夠去仔細的研究一下：

過分設計帶來的問題

上面的圖是新網銀行採購的一個項目，廠商提供的架構圖。其實需求很簡單，就是實現一個單點登陸。

在廠商提供的架構圖中，他們採用了微服務設計，利用了SpringCloud實現。根據廠商的設計，咱們須要50,60臺虛擬機來實現這個功能。

而這個系統的使用者有多少呢？400多人。由於是內部員工使用，因此只有400多人使用。

你作這麼複雜的一個設計，來支撐400多人的一個單點登陸功能？有沒有價值？有沒有性價比？

從這個例子中咱們能夠看出，你拆微服務，或者你需不須要拆、拆多細這個是和業務緊密相關的。

千萬不要爲了微服務而微服務，爲了技術而微服務。

這個地方和我以前在羣裏的一次聊天內容有點類似之處,離開業務談技術實現，都是耍流氓。

引伸思考

寫到這裏，我忽然想起以前在北京的支付公司作的時候碰到的一個需求，這個需求，在支付服務和清結算服務都能進行開發實現，可是這兩個服務都以爲本身不該該去作這個事情，即便這個需求必須由這兩個服務中的一個去實現。後來，咱們一塊兒去找了咱們的首席架構師，他說：這個需求，由清結算服務來作。由於對用戶來講，用戶更能直接感覺到的是支付服務。當咱們遇到須要開發一個功能的時候，應該開發在哪裏，這樣的邊界不清晰的問題的時候。個人答案是爲更多用戶能直觀感覺到的主要服務讓路。因此，這個需求由清結算服務實現。

最後說一點

若是須要2019年Dubbo開發者日成都站的講師PPT的話，能夠關注個人公衆號後，在公衆號後臺回覆關鍵字【1026】，爲何是1026，由於是10月26日舉行的活動。我會返回給你PPT的連接和觀看錄播的連接。悄悄的說一句：錄播裏面我也有露臉哦。

本文表明我的觀點，才疏學淺，不免會有紕漏。若是出現了錯誤的描述，也是我對謝老師的分享理解不到位，若是你發現了錯誤的地方，還請你留言給我指出來，我對其加以修改。

若是你以爲文章還不錯，你的點贊、留言、轉發、分享、讚揚就是對我最大的鼓勵。

以上。

謝謝您的閱讀，感謝您的關注。

歡迎關注公衆號【why技術】。