2019 中國.NET 開發者峯會目前在國內的.NET社區仍是頗有影響力的，宣傳的內容也都是比較新潮和前言的技術棧。html
有一個不爭的現實是基本上主題都是關於.NET Core的，以及基於該主題之上的延展。好比ML.NET相關的機器學習；基於.NET Core的微服務實戰；傳統轉型.NET Core的實戰；.NET Core在物聯網的應用；.NET Core結合K8S的應用；.NET Core架構歷史；.NET Core相關的雲原生技術等等。可謂欣欣向榮，百花齊放，彷彿讓人看到了.NET生態的從新崛起。git
峯會的內容給開發者開啓了一個明亮的窗口，但畢竟只是拋磚迎玉，真正落地開花還有很長的距離。數據庫
本人在.NET Core上面落地過，對微服務也興味黯然，因此我重點傾聽了劉騰飛老師的演講，並作部分解讀，從共鳴中寫下我的感想，但願對您有所啓發。後端
爲何選擇微服務？
雖然劉老師的說辭有點舉重若輕，說的是由於執着和技術人的專研精神選擇了微服務，甚至也對比和調研過，可是在只有四我的的團隊裏，連一張披薩都沒有湊齊的前提下就「冒然」選型，顯然不能讓我信服。多是劉大佬有比較充分的調研和把握，或者說有必定的技術自信。不然換成我，我是不管如何不敢帶着四個缺乏微服務實戰經驗的小夥伴貿然前進，除非我想把這個項目當成試驗品。設計模式
由於若是分層架構足夠規範簡單，團隊規範足夠精細，設計面向微服務的架構就足夠解決問題，等團隊和業務發展壯大後，再切換到微服務不遲。跨域
劉佬團隊中間加過多少班，踩過多少坑，也許只有劉老師知道。安全
演講中插曲說：有一次加班到凌晨3點多，而後一塊兒出來吃火鍋。我聽完除了敬佩仍是敬佩。有句話叫哪裏有歲月靜好，由於有人替你負載前行。架構
微服務難在哪裏？
由於微服務確實須要比較高的門檻，具體能夠參考個人另一篇文章《漫談什麼時候從單體架構遷移到微服務？》負載均衡
微服務的基礎設施包括：框架
- CI、CD，限流，熔斷，管理協做，分佈式技術，
- 網關，服務監控，日誌收集，重複代碼
- 配置中心，負載均衡，發佈成本
- 領域劃分和明確
- 容器相關技術棧等等
也就是說對於服務來講，單個服務變得簡單，總體服務變得複雜。
這些菜都端上來，若是沒有很好的技術儲備和高效管理和協做，估計是要不消化的。重點是劉大佬在演講最後，仍然沒有給提問者一個很好的關於分佈式事務的解決方案。
如何下降微服務的成本？
這裏的目的是探討如何下降成本，因此咱們必需要面對這些困難，一個一個的去解決。當這些困難的成本和單體一致或持續的接近單體的時候，我以爲上微服務就成竹在胸了。
爲此咱們必需要梳理並識別以上的技術難點，這裏挑選最核心的或者說最影響時間成本的點來展開。
引入K8S
面對JAVA的SPRING全家桶，劉佬採用K8S來解決，也就是說K8S自帶微服務等大部分基礎設施，好比配置中心不必定要用Appolo，使用K8S的ConfigMap就能夠了；服務發現和註冊也是K8S自帶的。K8S解決了基礎設施一半以上的問題，這個成本是很是低的。
也就是說對微服務的學習成本，變成了對K8S的學習成本。這對開發人員來講是個福音，由於能夠有現成的輪子，可是也不能高興太早，由於K8S並非一個容易掌握的技術。能夠說K8S內容龐雜，官方文檔也是大而全，想要一會兒掌握它非一日之寒。
剩下的另一半成本在哪兒？我以爲服務劃分，服務調用，相關提效工具的使用等等。
服務劃分
前期服務的劃分，包括基礎服務，核心服務，網關選型，全鏈路監控等技術棧。包括但不限於以下表所示：
服務調用：
- 服務在相互調用的時候，不免會產生重複模型，好比DTO。
- 使用HTTP請求的性能不足問題
- 採用gRPC
- 採用gRPC後服務開發解決單體開發，減小冗餘的代碼，作到分佈式部署和本地部署。
- 分佈式跨服務訪問，讀寫操做作分離，儘可能只作查詢，POST操做走異步消息事件。
劉佬提到的服務調用連續迭代了三個版本，這個坑給我很大啓發，雖然我目前的服務沒有采用gRPC，可是模型的代碼重複已經開始冗餘了。代碼冗餘不可避免，有沒有更好的解決方案呢？有些人會以爲引入Abp框架來解決，最新的Abp Next。這是很好的輪子，可是問題又來了，Abp Next和K8S同樣，若是團隊沒有好的研發型人員或者對Abp的使用有過幾個項目墊底的人，那麼Abp的引入可能會增長技術的複雜度，由於Abp在性能方面也是有坑的，況且Abp Next目前也在跟着迭代，文檔都不是很健全。
工具使用
工具是微服務基礎設施的一部分，好比基於gitLab的CI,CD或者jenkins。都是服務自動化發佈的利器。另外API接口膨脹後的管理，聯調，測試，規範等等，若是沒有管好API，先後端分離每每會下降咱們的開發效率，由於互相等待是常有的事情，就算模擬好數據後，也不能保證不去作聯調。
終極價值
劉佬說：「微服務的終極價值在於服務的任意拼裝組合。「
比如樂高積木，比起單體粗苯的代碼調整，顯然是高效率解放生產力的。這種價值其實並不新鮮，從歷史的維度看，從最小的函數封裝，抽象，設計模式，類庫，到進程交互，到最後亞馬遜的微服務發明，無不在學習樂高思想。只是隨着業務複雜度的增長，團隊規模的膨脹，這個樂高的粒度不斷的變大，變遠，最後跨進程，跨域，分佈式。
提問和啓發：
在演講結束的提問環節，問了三個問題我以爲頗有質量，也是難點。
如何保持數據一致性？
劉佬的項目在數據一致性這塊沒有落地，具體緣由沒說明，可是我預估當初是業務優先所作的妥協。
分佈式事務具有必定的複雜性，是個很大的話題。分佈式事務通常採用的是最終一致性，也就是CAP裏面的三選二，經過犧牲實時來保證業務的高可用性。電商中若是不涉及到資金安全，好比虛擬錢包和貨幣等核心業務功能，通常不影響使用。
而這裏的最終一致性要落地好，技術上雖然不難，可是要落地完整，須要很多時間。
如何解決K8S服務干擾？
某個服務由於各類緣由，好比代碼不夠健壯致使，或者由於ES的大內存需求，致使集羣其餘服務異常，甚至整個集羣垮掉該如何解決？
主要採用資源限制，可是資源限制會致使某個容器掛掉。能夠經過資源告警和日誌分析的方式快速定位容器並進行資源從新伸縮分配，特別是在生產環境。
如何解決數據庫運維？
隨着數據庫和服務一塊兒拆分，數據庫也變多了，給數據庫運維帶來了極大挑戰。
拆分的痛點是表關聯查詢，由於全部的聚合都是服務的聚合，也就是數據庫的Join沒有了，替換成的是服務間的關聯了，因此劉佬乾脆棄用MySQL，所有采用MongoDB，充分發揮MongoDB優點。
可是接下來的代價就是統計和報表的生成，這個難題也不復雜，能夠經過數據同步，把MongoDB的數據同步到關係型數據庫當中。
對於業務統計或用戶行爲事件，會產生很大的數據量，能夠在服務入口處作探針，好比在用戶訪問，下訂單服務處埋點，把訪問和統計數據同步到ES，發揮ES的威力，最後經過Dashboard來進行顯示。
