黄色日逼视频网站,男女插逼网站,av亚洲国产电影在线观看,水蜜桃视频网站在线观看,六月丁香婷婷网,国产福利在线视频,骚逼随便操,日韩无码A级

簡(jiǎn)介

這些年軟件的設(shè)計(jì)規(guī)模越來(lái)越龐大，業(yè)務(wù)需求也越來(lái)越復(fù)雜，針對(duì)系統(tǒng)的性能、高吞吐率、高穩(wěn)定性、高擴(kuò)展等特性提出了更高的要求。可以說(shuō)業(yè)務(wù)需求是軟件架構(gòu)能力的第一推動(dòng)力，由于這些因素導(dǎo)致了軟件架構(gòu)思想和相關(guān)技術(shù)也在發(fā)生著巨變。這些變化反應(yīng)在軟件架構(gòu)行業(yè)里，就是我們開(kāi)始越來(lái)越多的聽(tīng)到了很多新的詞匯，比如：“分布式”、“SOA”、“微服務(wù)”、“中臺(tái)”等概念。

今天我就把我學(xué)習(xí)微服務(wù)的過(guò)程記錄下來(lái)，包括所有技術(shù)的實(shí)現(xiàn)細(xì)節(jié)和個(gè)人的理解。俗話(huà)說(shuō)：好記性，不如爛筆頭，以防自己忘記，以后可以查詢(xún)。當(dāng)然，這些東西有很多東西都是自己的理解，里面的插圖也是自己畫(huà)的，可能會(huì)有一些有失偏頗的地方，當(dāng)然希望有高手可以指正，不靈賜教，大家共同進(jìn)步。

架構(gòu)發(fā)展歷程

現(xiàn)在的科學(xué)技術(shù)可以說(shuō)是日新月異，發(fā)展迅速。相對(duì)于我們軟件設(shè)計(jì)行業(yè)也在發(fā)生著巨變，業(yè)務(wù)越來(lái)越復(fù)雜，需求越來(lái)越龐大、繁雜，軟件架構(gòu)和部署的規(guī)模也發(fā)生著翻天覆地的變化，作為軟件架構(gòu)思想之一的“微服務(wù)架構(gòu)”也在按著自己的規(guī)律進(jìn)化著，接下來(lái)我們就簡(jiǎn)單的了解一下“微服務(wù)架構(gòu)”發(fā)展經(jīng)歷的三個(gè)時(shí)期，這些只是個(gè)人理解。

單體架構(gòu)（Monolithic）

單體應(yīng)用時(shí)代：應(yīng)用程序無(wú)論如何分層，都是一個(gè)解決方案，或者說(shuō)都是一個(gè)項(xiàng)目，這里的“解決方案”和“項(xiàng)目”不是我們使用的Visual Studio里面的概念，最終的程序代碼都會(huì)在一個(gè)進(jìn)程里運(yùn)行。如圖：

優(yōu)點(diǎn)：開(kāi)發(fā)簡(jiǎn)單，集中管理，沒(méi)有分布式的損耗，都是系統(tǒng)進(jìn)程內(nèi)的通信。

缺點(diǎn)：不好維護(hù)，升級(jí)困難，耦合嚴(yán)重，無(wú)法應(yīng)付高并發(fā)和大數(shù)據(jù)場(chǎng)景，無(wú)法快捷迭代。

只能采用同一種技術(shù)，很難用不同的語(yǔ)言或者相同語(yǔ)言不同版本開(kāi)發(fā)不同模塊。
系統(tǒng)耦合性太強(qiáng)，其中一個(gè)模塊有問(wèn)題，這個(gè)系統(tǒng)就會(huì)癱瘓，一個(gè)模塊升級(jí)，整個(gè)系統(tǒng)就得停機(jī)維護(hù)。
要上線(xiàn)，必須一起上線(xiàn)，互相等待，無(wú)法快速相應(yīng)市場(chǎng)需求。
集群負(fù)擔(dān)大，如果想要集群，只能對(duì)整個(gè)系統(tǒng)進(jìn)行集群，即使一個(gè)模塊有壓力。

垂直拆分

隨著業(yè)務(wù)規(guī)模的越來(lái)越龐大，系統(tǒng)設(shè)計(jì)就越來(lái)越復(fù)雜，大的系統(tǒng)就開(kāi)始進(jìn)行業(yè)務(wù)的垂直拆分。比如：有專(zhuān)門(mén)做商品秒殺的部門(mén)，有專(zhuān)門(mén)做生鮮商品的部門(mén)，有專(zhuān)門(mén)做超市的部門(mén)，等等，當(dāng)然這是根據(jù)部門(mén)天生劃分的，也有根據(jù)業(yè)務(wù)需求進(jìn)行系統(tǒng)劃分的。如圖：

優(yōu)點(diǎn)：垂直拆分，系統(tǒng)獨(dú)立部署和維護(hù)，每個(gè)系統(tǒng)在自己進(jìn)程內(nèi)執(zhí)行，分而治之。

缺點(diǎn)：拆分越多，存儲(chǔ)越復(fù)雜，系統(tǒng)間重復(fù)的東西也越多，單個(gè)系統(tǒng)還是單體模式。

分布式服務(wù)

隨著業(yè)務(wù)系統(tǒng)的越來(lái)越龐大，軟件系統(tǒng)設(shè)計(jì)起來(lái)越來(lái)越復(fù)雜。為了避免過(guò)度復(fù)雜的業(yè)務(wù)需求，開(kāi)始對(duì)業(yè)務(wù)系統(tǒng)的進(jìn)行垂直拆分，形成多個(gè)獨(dú)立的業(yè)務(wù)系統(tǒng)，如果多個(gè)系統(tǒng)之間要通信，可以通過(guò)跨進(jìn)程的技術(shù)完成通訊。但是垂直拆分也導(dǎo)致了大量重復(fù)代碼、重復(fù)模塊的產(chǎn)生，比如：用戶(hù)模塊、日志模塊、支付模塊、認(rèn)證授權(quán)模塊等，這樣分散的代碼也給系統(tǒng)的維護(hù)和升級(jí)帶來(lái)了困難。我們對(duì)業(yè)務(wù)重新劃分，把獨(dú)立的模塊接口化、服務(wù)化，提高重用，這個(gè)時(shí)候，我們就開(kāi)始進(jìn)入了分布式服務(wù)的時(shí)代。（分布式的第一要?jiǎng)?wù)就是不要分布式）如圖：

優(yōu)點(diǎn)：

獨(dú)立進(jìn)程部署，獨(dú)立進(jìn)程運(yùn)行，獨(dú)立演化。服務(wù)之間可以做到高內(nèi)聚，低耦合。
獨(dú)立開(kāi)發(fā)和維護(hù)，業(yè)務(wù)解耦，無(wú)論是業(yè)務(wù)系統(tǒng)還是分布式服務(wù)都獨(dú)立演化。
分布式管理
隔離性增強(qiáng)
由一系列服務(wù)組裝成系統(tǒng)，不用重復(fù)建設(shè)，模塊、代碼可以復(fù)用。

缺點(diǎn)：

數(shù)據(jù)一致性（多服務(wù)完成一個(gè)任務(wù)）和系統(tǒng)的可用性（集群）成為問(wèn)題
數(shù)據(jù)庫(kù)也進(jìn)行了拆分
維護(hù)、設(shè)計(jì)、架構(gòu)成本增加，調(diào)試、糾錯(cuò)更難
網(wǎng)絡(luò)傳輸分布式損耗成本
不適合高并發(fā)和大數(shù)據(jù)的環(huán)境

微服務(wù)架構(gòu)

微服務(wù)的出現(xiàn)時(shí)分布式架構(gòu)已經(jīng)很成熟了，架構(gòu)中各種問(wèn)題已經(jīng)有了很成熟的解決方案，對(duì)于現(xiàn)在的業(yè)務(wù)系統(tǒng)來(lái)說(shuō)，分布式架構(gòu)已經(jīng)變成了一種常規(guī)手段，這個(gè)時(shí)候，微服務(wù)就出現(xiàn)了。微服務(wù)架構(gòu)是一個(gè)用分布式服務(wù)拆分業(yè)務(wù)邏輯，完成解耦的架構(gòu)模式（架構(gòu)風(fēng)格）。微服務(wù)肯定是分布式的一種，是在分布式技術(shù)成熟之后，然后把分布式當(dāng)成解耦手段來(lái)架構(gòu)系統(tǒng)——因?yàn)椴鸱值姆?wù)很細(xì)致，服務(wù)數(shù)量規(guī)模開(kāi)始變多了，服務(wù)的體量開(kāi)始縮小了，由以前幾個(gè)大的服務(wù)，轉(zhuǎn)變?yōu)槎鄠€(gè)獨(dú)立運(yùn)行的、原子性質(zhì)的服務(wù)。如圖：

微服務(wù)最重要的特性是：

可用性：描述一個(gè)系統(tǒng)在一段時(shí)間內(nèi)提供有用資源的能力，從而減少停工時(shí)間，而保持其服務(wù)的高度可用性。
伸縮性：根據(jù)需求動(dòng)態(tài)添加和刪除系統(tǒng)中資源的能力，是水平或垂直擴(kuò)展的專(zhuān)門(mén)實(shí)現(xiàn)。

集群（負(fù)載均衡）可以解決系統(tǒng)的高可用和伸縮特性。

優(yōu)點(diǎn)：

可以使用不同語(yǔ)言或者相同語(yǔ)言的不同版本開(kāi)發(fā)各個(gè)模塊。
系統(tǒng)耦合性低，各個(gè)模塊分而治之，獨(dú)立部署，獨(dú)立發(fā)布，獨(dú)立維護(hù)。
可以更快的相應(yīng)市場(chǎng)的需求，更符合敏捷開(kāi)發(fā)。
可以對(duì)不同模塊使用集群策略，哪里有問(wèn)題治哪里。

缺點(diǎn)：

開(kāi)發(fā)難度更大，系統(tǒng)結(jié)構(gòu)更復(fù)雜。
運(yùn)行效率低，網(wǎng)絡(luò)調(diào)用成本很大。

SOA面向服務(wù)架構(gòu)

Service-Oriented Architecture面向服務(wù)架構(gòu)：是一個(gè)組件模型，它將應(yīng)用程序的不同功能單元（稱(chēng)為服務(wù)）進(jìn)行拆分，并通過(guò)這些服務(wù)之間定義良好的接口和協(xié)議聯(lián)系起來(lái)。如圖：

微服務(wù)架構(gòu)的發(fā)展歷程

我們要解決微服務(wù)的高可用和可伸縮的兩個(gè)問(wèn)題，自然就會(huì)想到通過(guò)集群來(lái)實(shí)現(xiàn)，這個(gè)思路沒(méi)有錯(cuò)。如果我們實(shí)現(xiàn)了服務(wù)集群，那另外兩個(gè)問(wèn)題就會(huì)出現(xiàn)，這兩個(gè)問(wèn)題也導(dǎo)致了微服務(wù)架構(gòu)的發(fā)展版本的差異。第一個(gè)：服務(wù)的發(fā)現(xiàn)問(wèn)題，調(diào)用方如何發(fā)現(xiàn)服務(wù)，有了新的服務(wù)，我們?nèi)绾沃溃蟹?wù)實(shí)例掉線(xiàn)，我們?nèi)绾螘缘茫l(fā)現(xiàn)服務(wù)就很重要，這個(gè)是基礎(chǔ)問(wèn)題，第一個(gè)問(wèn)題不解決，第二個(gè)問(wèn)題也沒(méi)有辦法實(shí)現(xiàn)；第二個(gè)：如何調(diào)用服務(wù)，如何管理那么多的服務(wù)實(shí)例。有那么多的集群實(shí)例，也就有那么多的服務(wù)實(shí)例，我們?cè)撛趺慈フ{(diào)用這些服務(wù)呢？多個(gè)服務(wù)調(diào)用的關(guān)系如何呢？

由于這些問(wèn)題，那我們就看看微服務(wù)架構(gòu)的三個(gè)版本是如何解決的。

集中式代理——Nginx V1.0版本（服務(wù)注冊(cè)/服務(wù)發(fā)現(xiàn)——手動(dòng)）

服務(wù)發(fā)現(xiàn)，手動(dòng)修改配置文件，重新啟動(dòng)。
負(fù)載均衡，可以輪訓(xùn)、權(quán)重、哈希等等。
服務(wù)新增無(wú)法發(fā)現(xiàn)，需要手動(dòng)配置，服務(wù)掉線(xiàn)可以自動(dòng)檢查。
客戶(hù)端的實(shí)現(xiàn)很簡(jiǎn)單，不需要額外的代碼，簡(jiǎn)單，高效。

客戶(hù)端嵌入——Consul V2.0版本（服務(wù)注冊(cè)/服務(wù)發(fā)現(xiàn)——自動(dòng)——服務(wù)治理）

服務(wù)注冊(cè)與發(fā)現(xiàn)，動(dòng)態(tài)增加，自動(dòng)完成。
健康檢查，可以查看損壞服務(wù)，去掉服務(wù)，自動(dòng)完成。
負(fù)載均衡，Consul返回所有活動(dòng)服務(wù)實(shí)例，客戶(hù)端自己實(shí)現(xiàn)負(fù)載均衡。

功能強(qiáng)大，自動(dòng)發(fā)現(xiàn)-自動(dòng)下線(xiàn)，客戶(hù)端集成比較復(fù)雜，負(fù)載均衡在客戶(hù)端實(shí)現(xiàn)。

服務(wù)網(wǎng)格——Service Mesh V3.0——技術(shù)不成熟，華為+唯品會(huì)，Istio

SideCar服務(wù)管理服務(wù)實(shí)例的注冊(cè)和發(fā)現(xiàn)，服務(wù)實(shí)例的治理和調(diào)用。Service Mesh’s Control Plan管理所有的SideCar。這個(gè)技術(shù)我就不多談了，網(wǎng)上的資料也很多，目前這個(gè)技術(shù)還不是很成熟，使用的范圍也不是很廣，只有一些大的公司有過(guò)使用，比如：微軟等。

微服務(wù)架構(gòu)必備技術(shù)棧

微服務(wù)是一種軟件設(shè)計(jì)、架構(gòu)思想，當(dāng)然，里面也包含了相關(guān)技術(shù)點(diǎn)要解決當(dāng)前要?jiǎng)?wù)。學(xué)習(xí)微服務(wù)，我們不能空口而談，一定要落實(shí)到具體的技術(shù)棧上。當(dāng)今使用比較多兩個(gè)技術(shù)體系，一個(gè)是Java，另外一個(gè)就是Net，廢話(huà)不多說(shuō)，我是使用微軟相關(guān)技術(shù)棧的軟件架構(gòu)人員，當(dāng)然使用的“微服務(wù)”架構(gòu)技術(shù)棧也都是微軟的。今天我就把相關(guān)“微服務(wù)架構(gòu)”所用到的技術(shù)棧羅列出來(lái)，我也要說(shuō)明一下，微服務(wù)架構(gòu)里面的很多技術(shù)是和開(kāi)發(fā)語(yǔ)言無(wú)關(guān)的，無(wú)論是.Net還是Java平臺(tái)都可以使用。以后，一步一步的針對(duì)每項(xiàng)技術(shù)在做深入研究。

微服務(wù)架構(gòu)——服務(wù)通信

WebService、WCF、WebAPI，甚至可以是ASHX，ASPX，這都是微軟本身的技術(shù)體系，沒(méi)什么可說(shuō)的。

主動(dòng)觸發(fā)
數(shù)據(jù)序列化傳遞
跨平臺(tái)
跨語(yǔ)言
Http穿透防火墻

微服務(wù)架構(gòu)——進(jìn)程通信

Net Remoting：Net平臺(tái)督郵的，不支持跨平臺(tái)。
gRPC：高性能、開(kāi)源和通用RPC框架，面向服務(wù)端和移動(dòng)端，基于HTTP/2設(shè)計(jì)，推薦使用。

微服務(wù)架構(gòu)——API網(wǎng)關(guān)服務(wù)（Ocelot）

API網(wǎng)關(guān)——它是系統(tǒng)的暴露在外部的一個(gè)訪(fǎng)問(wèn)入口。這個(gè)有點(diǎn)像代理訪(fǎng)問(wèn)的家伙，就像一個(gè)公司的門(mén)衛(wèi)承擔(dān)著尋址、限制進(jìn)入、安全檢查、位置引導(dǎo)、等等功能。Ocelot是一個(gè)用.NET Core實(shí)現(xiàn)并且開(kāi)源的API網(wǎng)關(guān)，它功能強(qiáng)大，包括了：路由、請(qǐng)求聚合、服務(wù)發(fā)現(xiàn)、認(rèn)證、鑒權(quán)、限流熔斷、并內(nèi)置了負(fù)載均衡器與Service Fabric、Butterfly Tracing集成。這些功能只都只需要簡(jiǎn)單的配置即可完成。如圖：

官網(wǎng)：https://ocelot.readthedocs.io/en/latest/index.html

微服務(wù)架構(gòu)——認(rèn)證&授權(quán)

現(xiàn)在的應(yīng)用開(kāi)發(fā)層出不窮，基于瀏覽器的網(wǎng)頁(yè)應(yīng)用，基于微信的公眾號(hào)、小程序，基于iOS、Android的App，基于Windows系統(tǒng)的桌面應(yīng)用和UWP應(yīng)用等等，這么多種類(lèi)的應(yīng)用，就給應(yīng)用的開(kāi)發(fā)帶來(lái)的挑戰(zhàn)，我們除了分別實(shí)現(xiàn)各個(gè)應(yīng)用外，我們還要考慮各個(gè)應(yīng)用之間的交互，通用模塊的提煉，其中身份的認(rèn)證和授權(quán)就是每個(gè)應(yīng)用必不可少的的一部分。而現(xiàn)在的互聯(lián)網(wǎng)，對(duì)于信息安全要求又十分苛刻，所以一套統(tǒng)一的身份認(rèn)證和授權(quán)就至關(guān)重要。

IdentityServer4就是這樣一個(gè)框架，IdentityServer4是為ASP.NET CORE量身定制的實(shí)現(xiàn)了OpenId Connect和OAuth2.0協(xié)議的認(rèn)證授權(quán)中間件。

項(xiàng)目地址：https://github.com/IdentityServer/IdentityServer4

微服務(wù)架構(gòu)——瞬態(tài)故障處理

Polly它一款強(qiáng)大的類(lèi)庫(kù)，Polly是一種.NET彈性和瞬態(tài)故障處理庫(kù)，允許我們以非常順暢和線(xiàn)程安全的方式來(lái)執(zhí)諸如行重試，斷路，超時(shí)，故障恢復(fù)等策略。Polly針對(duì).NET 4.0，.NET 4.5和.NET Standard 1.1以及.NET Core實(shí)現(xiàn)，該項(xiàng)目作者現(xiàn)已成為.NET基金會(huì)一員，項(xiàng)目一直在不停迭代和更新，你值得擁有。

項(xiàng)目地址：https://github.com/App-vNext/Polly

微服務(wù)架構(gòu)——分布式追蹤

隨著微服務(wù)架構(gòu)的流行，一些微服務(wù)架構(gòu)下的問(wèn)題也會(huì)越來(lái)越突出，比如一個(gè)請(qǐng)求會(huì)涉及多個(gè)服務(wù)，而服務(wù)本身可能也會(huì)依賴(lài)其他服務(wù)，整個(gè)請(qǐng)求路徑就構(gòu)成了一個(gè)網(wǎng)狀的調(diào)用鏈，而在整個(gè)調(diào)用鏈中一旦某個(gè)節(jié)點(diǎn)發(fā)生異常，整個(gè)調(diào)用鏈的穩(wěn)定性就會(huì)受到影響，所以會(huì)深深的感受到“銀彈”這個(gè)詞是不存在的，每種架構(gòu)都有其優(yōu)缺點(diǎn)。

面對(duì)以上情況，我們就需要一些可以幫助理解系統(tǒng)行為、用于分析性能問(wèn)題的工具，以便發(fā)生故障的時(shí)候，能夠快速定位和解決問(wèn)題，這時(shí)候APM（應(yīng)用性能管理）工具就該閃亮登場(chǎng)了。

項(xiàng)目地址：https://github.com/SkyAPM/SkyAPM-dotnet

微服務(wù)架構(gòu)——分布式日志

一般我們需要進(jìn)行日志分析場(chǎng)景：直接在日志文件中g(shù)rep、awk就可以獲得自己想要的信息。但在規(guī)模較大也就是日志量多而復(fù)雜的場(chǎng)景中，此方法效率低下，面臨問(wèn)題包括日志量太大如何歸檔、文本搜索太慢怎么辦、如何多維度查詢(xún)。需要集中化的日志管理，所有服務(wù)器上的日志收集匯總。常見(jiàn)解決思路是建立集中式日志收集系統(tǒng)，將所有節(jié)點(diǎn)上的日志統(tǒng)一收集，管理，訪(fǎng)問(wèn)。

大型系統(tǒng)通常都是一個(gè)分布式部署的架構(gòu)，不同的服務(wù)模塊部署在不同的服務(wù)器上，問(wèn)題出現(xiàn)時(shí)，大部分情況需要根據(jù)問(wèn)題暴露的關(guān)鍵信息，定位到具體的服務(wù)器和服務(wù)模塊，構(gòu)建一套集中式日志系統(tǒng)，可以提高定位問(wèn)題的效率。

Exceptionless是一個(gè)開(kāi)源的實(shí)時(shí)的日志收集框架，它可以應(yīng)用在基于ASP.NET，ASP.NET Core，Web Api，Web Forms，WPF，Console，MVC等技術(shù)棧的應(yīng)用程序中，并且提供了Rest接口可以應(yīng)用在Javascript，Node.js中。它將日志收集變得簡(jiǎn)單易用并且不需要了解太多的相關(guān)技術(shù)細(xì)節(jié)及配置。在以前，我們做日志收集大多使用Log4net，Nlog等框架，在應(yīng)用程序變得復(fù)雜并且集群的時(shí)候，可能傳統(tǒng)的方式已經(jīng)不是很好的適用了，因?yàn)槭占鱾€(gè)日志并且分析他們將變得麻煩而且浪費(fèi)時(shí)間。

現(xiàn)在Exceptionless團(tuán)隊(duì)給我們提供了一個(gè)更好的框架來(lái)做這件事情，我認(rèn)為這是非常偉大并且有意義的，感謝他們。

官網(wǎng)：http://exceptionless.com/

GitHub：https://github.com/exceptionless/Exceptionless

ELK是三個(gè)開(kāi)源軟件的縮寫(xiě)，分別為：Elasticsearch、Logstash以及Kibana，它們都是開(kāi)源軟件。不過(guò)現(xiàn)在還新增了一個(gè)Beats，它是一個(gè)輕量級(jí)的日志收集處理工具（Agent），Beats占用資源少，適合于在各個(gè)服務(wù)器上搜集日志后傳輸給Logstash，官方也推薦此工具，目前由于原本的ELK Stack成員中加入了Beats工具所以已改名為Elastic Stack。推薦使用。

微服務(wù)架構(gòu)——分布式配置中心

Apollo（阿波羅）是攜程框架部門(mén)研發(fā)的配置管理平臺(tái)，能夠集中化管理應(yīng)用不同環(huán)境、不同集群的配置，配置修改后能夠?qū)崟r(shí)推送到應(yīng)用端，并且具備規(guī)范的權(quán)限、流程治理等特性。

服務(wù)端基于Spring Boot和Spring Cloud開(kāi)發(fā)，打包后可以直接運(yùn)行，不需要額外安裝Tomcat等應(yīng)用容器。

Java客戶(hù)端不依賴(lài)任何框架，能夠運(yùn)行于所有Java運(yùn)行時(shí)環(huán)境，同時(shí)對(duì)Spring環(huán)境也有較好的支持。

.Net客戶(hù)端不依賴(lài)任何框架，能夠運(yùn)行于所有.Net運(yùn)行時(shí)環(huán)境。

項(xiàng)目地址：https://github.com/ctripcorp/apollo/

微服務(wù)架構(gòu)——分布式鎖

分布式鎖的解決方案有很多，我在這里就羅列一些，我會(huì)在以后的實(shí)踐中實(shí)現(xiàn)這些技術(shù)點(diǎn)。

Consul可以實(shí)現(xiàn)分布式鎖
Redis可以實(shí)現(xiàn)分布式鎖，推薦使用。
ZooKeeper可以實(shí)現(xiàn)分布式鎖
數(shù)據(jù)庫(kù)可以實(shí)現(xiàn)分布式鎖

微服務(wù)架構(gòu)——分布式事務(wù)

分布式事務(wù)的實(shí)現(xiàn)方式也不少，以后努力學(xué)習(xí)吧。

2PC（two-phase commit protocol，強(qiáng)一致性，沒(méi)有可用性）
3PC
TCC（Try-Confirm-Cancel）
本地消息表，推薦RabbitMQ
Saga模式

本地消息表：MQ分布式事務(wù)—本地消息表—基于消息的一致性。

上游投遞消息
下游獲取消息
上游投遞穩(wěn)定性
下游接受穩(wěn)定性

微服務(wù)架構(gòu)——容器化

Docker是一個(gè)開(kāi)源的應(yīng)用容器引擎，可以打包應(yīng)用以及依賴(lài)包到一個(gè)可移植的鏡像中，然后發(fā)布到任何流行的Linux和Windows機(jī)器上，也可以實(shí)現(xiàn)虛擬化。

Docker使用客戶(hù)端-服務(wù)器（C/S）架構(gòu)模式，使用遠(yuǎn)程API來(lái)管理和創(chuàng)建Docker容器。Docker容器通過(guò)Docker鏡像來(lái)創(chuàng)建。容器與鏡像的關(guān)系類(lèi)似于面向?qū)ο缶幊讨械膶?duì)象與類(lèi)。

Docker采用C/S架構(gòu)Docker daemon作為服務(wù)端接受來(lái)自客戶(hù)的請(qǐng)求，并處理這些請(qǐng)求（創(chuàng)建、運(yùn)行、分發(fā)容器）。客戶(hù)端和服務(wù)端既可以運(yùn)行在一個(gè)機(jī)器上，也可通過(guò)socket或者RESTful API來(lái)進(jìn)行通信。

Docker daemon一般在宿主主機(jī)后臺(tái)運(yùn)行，等待接收來(lái)自客戶(hù)端的消息。Docker客戶(hù)端則為用戶(hù)提供一系列可執(zhí)行命令，用戶(hù)用這些命令實(shí)現(xiàn)跟Docker daemon交互。如圖：

微服務(wù)架構(gòu)——容器編排

Kubernetes是Google開(kāi)源的一個(gè)容器編排引擎，它支持自動(dòng)化部署、大規(guī)模可伸縮、應(yīng)用容器化管理。在生產(chǎn)環(huán)境中部署一個(gè)應(yīng)用程序時(shí)，通常要部署該應(yīng)用的多個(gè)實(shí)例以便對(duì)應(yīng)用請(qǐng)求進(jìn)行負(fù)載均衡。

在Kubernetes中，我們可以創(chuàng)建多個(gè)容器，每個(gè)容器里面運(yùn)行一個(gè)應(yīng)用實(shí)例，然后通過(guò)內(nèi)置的負(fù)載均衡策略，實(shí)現(xiàn)對(duì)這一組應(yīng)用實(shí)例的管理、發(fā)現(xiàn)、訪(fǎng)問(wèn)，而這些細(xì)節(jié)都不需要運(yùn)維人員去進(jìn)行復(fù)雜的手工配置和處理。

Kubernetes也可以理解為Docker的編排容器，是管理應(yīng)用的全生命周期的工具，從創(chuàng)建應(yīng)用/部署，應(yīng)用提供服務(wù)，擴(kuò)容縮容，更新，都非常的方便，而且可以做到故障自愈。

官網(wǎng)：https://kubernetes.io/docs/home/

微服務(wù)架構(gòu)——CI/CD

Jenkins是一個(gè)開(kāi)源的、提供友好操作界面的持續(xù)集成（CI）工具，主要用于持續(xù)、自動(dòng)的構(gòu)建/測(cè)試軟件項(xiàng)目、監(jiān)控外部任務(wù)的運(yùn)行。

官網(wǎng)：https://www.jenkins.io/

結(jié)束語(yǔ)

好了，今天就寫(xiě)到這里了，沒(méi)別的，就是做一下相關(guān)技術(shù)棧的記錄，以后有時(shí)間，再把每項(xiàng)技術(shù)仔細(xì)研究，可能是每項(xiàng)技術(shù)，也可能是以一個(gè)項(xiàng)目來(lái)研究，這個(gè)項(xiàng)目中可能包含很多其他的技術(shù)，到時(shí)候，再?zèng)Q定。每天進(jìn)步一點(diǎn)，加油。

原文鏈接：https://www.cnblogs.com/PatrickLiu/p/13925259.html

文章轉(zhuǎn)載：分布式實(shí)驗(yàn)室
（版權(quán)歸原作者所有，侵刪）

微服務(wù)及技術(shù)棧介紹

簡(jiǎn)介

架構(gòu)發(fā)展歷程

微服務(wù)架構(gòu)的發(fā)展歷程

微服務(wù)架構(gòu)必備技術(shù)棧

結(jié)束語(yǔ)