本文首發於公眾號，關注文末公眾號，閱讀體驗更佳。
2019年Dubbo社群開發者日成都站一共有七位老師進行了分享。你想要了解他們都分享了些啥嗎？
我的收穫
進入會場的時候可以在接待臺的地方拿到七個摺頁，每一個摺頁都是阿里對開源社群的共享，每一個摺頁的背後都代表著一個團隊的辛勤付出，他們為中國在世界的開源史上落下了濃墨重彩的一筆。值得尊重，我也必須一一打出來，以示尊重。它們分別是: 【Dubbo】國內最受歡迎的服務框架、服務化/微服務最佳解決方案。 【阿里巴巴Spring Cloud】微服務開發一站式解決方案。 【Nacos】一個更易於構建元原生應用的動態服務發現配置管理和服務管理平臺。 【ChaosBlade】阿里巴巴開源的一款簡單易用、功能強大的混沌實驗注入工具。 【Alibaba Java】應用診斷利器。 【Dragonfly】元原生的映象與檔案分發解決方案。 【Sentinel】The Flow Sentinel of your Microservices
這次成都的Dubbo社群開發者日宣傳海報上一共有六個議題.
但是實際上來分享的老師有七位。
在活動開始之前還有一個暖場的小活動。就是做一個簡單的自我介紹，然後介紹的比較好的，阿里的小姐姐會送一本小馬哥寫的《SprintBoot程式設計思想》，還是簽名版哦。
這環節是我的強項啊。所以，當仁不讓，我有幸獲得了這個獎品。謝謝小姐姐，謝謝小馬哥。
同時，在自我介紹的環節，我驚奇的發現，我旁邊的這個哥們，居然閱讀過我的公眾號文章。在會議進行的過程中，我更加驚奇的發現，我右前方的哥們也讀過我公眾號的文章。
這就很神奇了。
微服務轉型
在這七個優秀的分享中，每一個都可以拿出來單獨寫一篇文章，如果一篇文章包含了所有的分享，那大概率是泛泛而談了。
我不想泛泛而談，所以在這篇文章裡我只寫一個主題：來自新網銀行謝延澤老師的分享。
謝老師分享主題是《新網銀行微服務轉型實踐》，主要是關於微服務落地的相關內容。我會結合謝老師的PPT來分享一下我的一些思考。
Part 1 新網銀行簡介
謝老師的第一部分分享的內容是新網銀行的簡介。我擷取其中表現資料的PPT給大家分享一下,畢竟大家都是對資料、對流量比較感興趣的。
中國傳統銀行，比如四大行：中國工商銀行、中國農業銀行、中國銀行、中國建設銀行。你可以在全國各地看到他們的分支機構，每個分支機構裡面有若干個客戶經理再引導你做各種業務，其中一大業務就是存錢、取錢。
你在傳統銀行裡能看到的，在新網銀行都看不到。我們沒有分支機構(強行說的話算是有一個，但是其作用主要是為了展示品牌用)、沒有客戶經理、沒用現金業務。
在《銀行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技術】。