微服務引言

微服務出現的動機,現在業務變革太快了,要求技術架構需要跟上變化,

從單體架構到soa架構到微服務架構,靈活性,輕快做了進一步演進,從網際網路公司到企業級的應用CRM系統,金融系統

不僅僅是應用的架構,自組織團隊,完成分析開發測試部署運維,7~8個人;技術實踐;流程與工具

Serverless(微服務),Martin Flower(發明人),獨立部署,獨立演進,允許技術多樣性,模組化邊界性

原來只需要運維一個應用,現在需要應用多個

原來單體呼叫(在程序內),現在要遠端呼叫,慢,可靠性

單體應用用資料庫的事務保持一致性,但是微服務有多個數據庫,可以多例項連線一個數據庫,用最合適的資料庫技術,原來是關係型資料庫,EJB強事務,但現在有些用redis和mongDB非關係型資料庫

微服務架構解決方案

華為雲微服務產品,微服務引擎CSE微服務引擎

降級,訪問劇增的時候把一些服務關閉,頁面上也不會顯示相關的內容

灰度釋出:有兩個版本,一個是1.0版本,一個而是2.0版本,2.0版本的篩選條件設定為成都,即在搜尋別的城市,eg廣州的時候

選擇1.0版本,搜尋成都的時候選擇2.0版本.

微服務治理之負載均衡,分發到多個伺服器,提供響應反應快的例項,提供最快的告訴

微服務治理之限流,超過限流請求量,防止故障蔓延

微服務治理之熔斷,可能有級聯故障,有因服務者不可用導致"呼叫服務者不可用"的問題,當視窗請求數超過20,或者失敗率超過60%之後,熔斷5000ms後再次恢復

微服務治理之容錯,提供四種容錯機制,出現異常以後的策略failover:失敗後自動切換,在其他機器上進行測試;Failfast:失敗後立即返回結果,不重試

Failback:失敗後在同一個伺服器上重試;custom:自定義;

CES開源版本ServiceComb

ServiceComb基於華為內部的CSE(Cloud Service Engine)框架開源而來，這個框架在華為內部已經存在了2年多，支撐了多個大型的商業專案。有相對傳統的企業級專案，也有類似手機應用這樣的網際網路屬性比較強的專案。並且在成為整個華為公司統一的微服務標準框架後，依然有越來越多的產品在逐漸使用它開發自己的微服務。

“不用SpringBoot的原因”，這個問題本身就有問題，因為ServiceComb並不阻礙你用SpringBoot，也不阻礙你用SpringCloud。如果你用這兩個技術，可以把ServiceComb當做封裝好了的幾個starter，可以讓你更方便地構建你的應用，就像樓主同學所說，在ServiceComb裡面對Netflix OSS的一些元件做了很深度的整合和封裝，不像SpringCloud這樣一個大雜燴，在ServiceComb裡面從頭到尾進行了封裝。你可以把它想象成是提供了類似Fegin的標記式開發方式，提供了SpringMVC的開發方式，提供了JAXRS的開發方式，然後對於你來說，這就夠了，因為你用了這些開發方式開發了程式碼以後，LB、Hystrix已經被封裝在後面了，你不用自己再去構建Command來用Hystrix。當然，如果你想自己擴充套件也可以。但是你也真的可以不用SpringBoot而只用ServiceComb。原因麼，內部產品太多，各個團隊水平和情況各不相同，有的就是不願意用SpringBoot我們也沒辦法。動不動就說影響了他們幾個億的大買賣我們也很無奈啊。所以其實ServiceComb的第一個內部版本我們是依賴SpringBoot的，但是後面逐漸優化逐漸瘦身，開出來的版本已經不再強依賴SpringBoot了（注意，不依賴不表示不能一起用）。

對於Dubbo，微服務不是說好了“各個微服務用最適合的語言寫不能繫結語言”嗎？不是說好的“每個程序是一個微服務”嗎？所以我們認為它是一個非常優秀的SOA時代的RPC框架，但是就微服務而言，它還有一些問題。

微服務全生命週期管理

微服務開發生命管理

微服務運維生命管理