.netcore下的微服务、容器、运维、自动化发布
微服務(wù)
1.1???? 基本概念
1.1.1?????? 什么是微服務(wù)?
微服務(wù)架構(gòu)是SOA思想某一種具體實(shí)現(xiàn)。是一種將單應(yīng)用程序作為一套小型服務(wù)開(kāi)發(fā)的方法,每種應(yīng)用程序都在其自己的進(jìn)程中運(yùn)行,并采用輕量級(jí)的通訊機(jī)制(TCP)進(jìn)行通信。這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的,可以通過(guò)全自動(dòng)部署機(jī)制進(jìn)行獨(dú)立部署。這些服務(wù)的集中化管理已經(jīng)是最少的,它們可以用不同的編程語(yǔ)言編寫(xiě),并使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)。
1.1.2?????? 為什么要用微服務(wù)?
1.1.2.1?? 微服務(wù)解決了什么問(wèn)題?
??? 在微服務(wù)的最佳實(shí)踐中都提到如果一個(gè)項(xiàng)目以微服務(wù)作為起點(diǎn),則大概率會(huì)陷入項(xiàng)目失敗。微服務(wù)的本質(zhì)是解決了團(tuán)隊(duì)分工的問(wèn)題,當(dāng)項(xiàng)目團(tuán)隊(duì)的開(kāi)發(fā)人員無(wú)法解決大型單體應(yīng)用的問(wèn)題或雖然可以解決問(wèn)題但成本高昂的時(shí)候,微服務(wù)往往才是最佳實(shí)踐。通過(guò)從外圍不斷拆分單體架構(gòu)的業(yè)務(wù),以細(xì)粒度的單項(xiàng)服務(wù)的形式發(fā)布服務(wù),最終將單體架構(gòu)微服務(wù)化。
1.1.2.2?? 微服務(wù)帶來(lái)了什么挑戰(zhàn)?
微服務(wù)首先是對(duì)組織架構(gòu)的調(diào)整提出的新的挑戰(zhàn),微服務(wù)要求每一個(gè)服務(wù)盡可能的獨(dú)立和內(nèi)聚,這要求這個(gè)團(tuán)隊(duì)符合2pizza風(fēng)格,也就是說(shuō)每一個(gè)團(tuán)隊(duì)都盡可能的包含從開(kāi)發(fā)到測(cè)試到運(yùn)維人員組成的獨(dú)立項(xiàng)目組。而不是傳統(tǒng)大型企業(yè)中以橫向切割的形式讓開(kāi)發(fā)、運(yùn)維、測(cè)試各是一個(gè)獨(dú)立部門(mén)。
微服務(wù)的第二個(gè)挑戰(zhàn)是帶來(lái)了分布式下開(kāi)發(fā)、測(cè)試與運(yùn)維的復(fù)雜性。微服務(wù)本質(zhì)上并不是什么銀彈,它解決了團(tuán)隊(duì)面對(duì)單體架構(gòu)疲于奔命的開(kāi)發(fā)和部署問(wèn)題,但是也引來(lái)了新的問(wèn)題。在單體開(kāi)發(fā)過(guò)程中,開(kāi)發(fā)人員不會(huì)想到方法調(diào)用會(huì)失敗、會(huì)重試、要冪等。測(cè)試人員不會(huì)考慮幾十個(gè)應(yīng)用怎么一起集成測(cè)試,運(yùn)維人員不會(huì)考慮下游應(yīng)用掛了對(duì)我有什么影響。意識(shí)到分布式下開(kāi)發(fā)、測(cè)試與運(yùn)維的復(fù)雜性,并掌握這些復(fù)雜問(wèn)題的方法才是更主要的。
1.2???? 架構(gòu)設(shè)計(jì)
1.2.1?????? 服務(wù)注冊(cè)/發(fā)現(xiàn)
服務(wù)治理解決了分布式應(yīng)用中服務(wù)依賴復(fù)雜度的問(wèn)題,當(dāng)數(shù)十個(gè)應(yīng)用需要統(tǒng)一的管理進(jìn)行服務(wù)發(fā)現(xiàn)、負(fù)載均衡、服務(wù)降級(jí)、服務(wù)下線時(shí)。沒(méi)有一個(gè)統(tǒng)一的管理方式是無(wú)法實(shí)現(xiàn)的,服務(wù)治理的概念也應(yīng)運(yùn)而生。服務(wù)治理中最重要的部分就是服務(wù)的注冊(cè)和發(fā)現(xiàn),以dubbo為例,服務(wù)提供者啟動(dòng)后向注冊(cè)中心注冊(cè)自己提供的服務(wù)。消費(fèi)者(有可能是其他服務(wù)、也有可能是網(wǎng)關(guān))啟動(dòng),向注冊(cè)中心訂閱自己需要的服務(wù)。注冊(cè)中心返回服務(wù)提供者的健康檢查(心跳)列表,消費(fèi)者根據(jù)軟負(fù)載算法(輪詢/隨機(jī)/hash一致/最小壓力優(yōu)先)選擇一臺(tái)發(fā)起請(qǐng)求。
?
1.2.2?????? 分布式通訊
1.2.2.1?? REST API/RPC
一般在微服務(wù)架構(gòu)中,服務(wù)和服務(wù)之間由于進(jìn)程隔離甚至物理機(jī)隔離,往往會(huì)采用一種通用的網(wǎng)絡(luò)通訊模式,以目前主流的設(shè)計(jì)來(lái)說(shuō)有兩種方案,一種是基于HTTP協(xié)議的rest api方式。這種方式下每一個(gè)生產(chǎn)者以rest api的形式暴露自己的接口到注冊(cè)中心。消費(fèi)者從注冊(cè)中心拉取到生產(chǎn)者列表后通過(guò)httpclient的形式發(fā)起請(qǐng)求并獲得結(jié)果。Rpc協(xié)議也是基于網(wǎng)絡(luò)的請(qǐng)求協(xié)議,rpc通過(guò)TCP的形式(如dotnetty)采用遠(yuǎn)程過(guò)程調(diào)用的方式,讓本地應(yīng)用調(diào)用遠(yuǎn)程應(yīng)用就和調(diào)用本地過(guò)程一樣方便(new remoteprocessserver().get({id=1}))。
1.2.2.2?? 事件總線
微服務(wù)中由于服務(wù)和服務(wù)之間采用了物理級(jí)的數(shù)據(jù)隔離機(jī)制,而在單體架構(gòu)中很容易實(shí)現(xiàn)的事務(wù)在微服務(wù)中成了復(fù)雜的分布式問(wèn)題,目前的解決辦法是引入事件總線(event bus)的機(jī)制來(lái)實(shí)現(xiàn)分布式環(huán)境下的事務(wù)問(wèn)題,事件總線采用了觀察者模式,通過(guò)訂閱發(fā)布到事件總線來(lái)實(shí)現(xiàn)消息的最終一致性。訂閱者訂閱消息,發(fā)布者產(chǎn)生消息后發(fā)布到事件總線,事件總線異步通知(基于第三方的消息隊(duì)列,如rabbitmq)訂閱者,訂閱者處理消息。訂閱者可以通過(guò)一些機(jī)制比如重試和冪等機(jī)制保證消費(fèi)的消息一定能夠被消費(fèi)一次。如果稍微復(fù)雜則需要引入TCC這樣的機(jī)制保證消息消費(fèi)失敗可以及時(shí)回滾(.netcore目前國(guó)內(nèi)有開(kāi)源的CAP可以實(shí)現(xiàn)eventbus并內(nèi)置的tcc,無(wú)需開(kāi)發(fā)者實(shí)現(xiàn)復(fù)雜的應(yīng)用層tcc)
1.2.3?????? 網(wǎng)關(guān)
微服務(wù)中,網(wǎng)關(guān)是所有服務(wù)對(duì)外提供的一個(gè)統(tǒng)一窗口。網(wǎng)關(guān)本質(zhì)就是一個(gè)路由器,通過(guò)這個(gè)路由器,我們可以將外界(PC/APP/IOT/CLOUD)的請(qǐng)求進(jìn)行統(tǒng)一的鑒權(quán)、限流、監(jiān)控后對(duì)內(nèi)調(diào)用服務(wù),從而起到了保護(hù)內(nèi)部服務(wù)接口安全的目的。
1.2.3.1?? 服務(wù)鑒權(quán)
用戶調(diào)用的某一個(gè)接口需要進(jìn)行權(quán)限身份驗(yàn)證時(shí),可以通過(guò)網(wǎng)關(guān)集成identity進(jìn)行統(tǒng)一的鑒權(quán)管理,而無(wú)需每一個(gè)應(yīng)用自己去實(shí)現(xiàn)鑒權(quán)。也可以通過(guò)獨(dú)立的授權(quán)服務(wù)器來(lái)處理,網(wǎng)關(guān)將每一個(gè)需要鑒權(quán)的請(qǐng)求通過(guò)授權(quán)服務(wù)器做校驗(yàn),再由授權(quán)服務(wù)器授權(quán)后通知網(wǎng)關(guān)調(diào)用具體的服務(wù)
1.2.3.2?? 服務(wù)限流
網(wǎng)關(guān)可以通過(guò)對(duì)每個(gè)服務(wù)進(jìn)行限流來(lái)保障在高并發(fā)中服務(wù)因?yàn)闊o(wú)法及時(shí)處理請(qǐng)求而掛掉,比如當(dāng)某個(gè)服務(wù)的請(qǐng)求在單位時(shí)間內(nèi)超過(guò)了設(shè)定閾值,則網(wǎng)關(guān)可以直接返回給調(diào)用者一個(gè)友好的回調(diào)或者通過(guò)緩存的形式返回之前的結(jié)果。
?
1.2.3.3?? 熔斷降級(jí)
網(wǎng)關(guān)可以通過(guò)熔斷的機(jī)制來(lái)保障某一個(gè)服務(wù)的可用性,比如當(dāng)某個(gè)服務(wù)變得不可用的時(shí)候,比如當(dāng)調(diào)用者多次請(qǐng)求某個(gè)服務(wù)都超時(shí),當(dāng)超時(shí)次數(shù)超過(guò)設(shè)定閾值的時(shí)候,網(wǎng)關(guān)可以對(duì)該類型的服務(wù)進(jìn)行熔斷,所有對(duì)該服務(wù)的請(qǐng)求都會(huì)收到網(wǎng)關(guān)的友好回調(diào)或舊緩存。網(wǎng)關(guān)會(huì)在熔斷時(shí)啟動(dòng)一個(gè)定時(shí)作業(yè)定時(shí)檢查該服務(wù)的可用性,直到該服務(wù)重新可以被訪問(wèn)時(shí)才能重新接入網(wǎng)關(guān)
?
1.2.4?????? 配置中心
單體式應(yīng)用中,一般采用傳統(tǒng)的配置文件的形式進(jìn)行本地化配置,方便統(tǒng)一管理或熱更新。但是在分布式環(huán)境下如果沒(méi)有一個(gè)分布式的配置中心作為支撐,動(dòng)輒幾百個(gè)微服務(wù)應(yīng)用是沒(méi)辦法及時(shí)進(jìn)行統(tǒng)一配置的。所以一個(gè)統(tǒng)一的分布式配置中心是有必要存在的。通過(guò)統(tǒng)一的配置中心管理所有應(yīng)用的配置,應(yīng)用通過(guò)初始化拉取的形式做更新。應(yīng)用內(nèi)部依舊采用熱更新的形式讀取配置數(shù)據(jù)。
?
1.2.5?????? 下一代微服務(wù)架構(gòu)
1.2.5.1?? Service Mesh
這一套解決方案提供了一套基于基礎(chǔ)設(shè)施的,對(duì)語(yǔ)言和應(yīng)用本身無(wú)依賴的服務(wù)網(wǎng)格來(lái)提供上一代微服務(wù)中心化的網(wǎng)關(guān)/注冊(cè)中心/緩存/負(fù)載均衡等等功能。比如基于k8s實(shí)現(xiàn)的istio。本質(zhì)上是通過(guò)對(duì)容器注入sidercar的形式無(wú)感知的實(shí)現(xiàn)服務(wù)治理。而無(wú)需關(guān)注服務(wù)本身是用何種語(yǔ)言編寫(xiě)的何種服務(wù)。Service fabric也是提供類似的功能的平臺(tái)。
1.2.5.2??? Serverless
Serverless 是提供微服務(wù)的一種簡(jiǎn)化開(kāi)發(fā)、自動(dòng)化運(yùn)維、資源分時(shí)復(fù)用的解決方案,比如Flink(略)
?
1.3???? 具體實(shí)踐
1.3.1?????? 如何通過(guò).netcore+surging+DDD實(shí)現(xiàn)微服務(wù)?
surging 是一個(gè)分布式微服務(wù)框架,提供高性能RPC遠(yuǎn)程服務(wù)調(diào)用,服務(wù)引擎支持http、TCP、WS協(xié)議,采用Zookeeper、Consul作為surging服務(wù)的注冊(cè)中心,集成了哈希,隨機(jī),輪詢、壓力最小優(yōu)先作為負(fù)載均衡的算法,RPC集成采用的是netty框架,采用異步傳輸。項(xiàng)目地址https://github.com/dotnetcore/surging
在surging的基礎(chǔ)上我進(jìn)行了一些本地化實(shí)現(xiàn),比如授權(quán)服務(wù)分離。并為應(yīng)用提供了一套ddd的基礎(chǔ)設(shè)施以及自動(dòng)發(fā)布以及運(yùn)維監(jiān)控部分的集成。項(xiàng)目地址https://gitee.com/gmmy/Microservices
?
容器(docker)
2.1???? 基本概念
2.1.1?????? 什么是容器?
容器基于Linux Container技術(shù),它是一種內(nèi)核輕量級(jí)的操作系統(tǒng)層虛擬化技術(shù)。最單純的理解就是通過(guò)容器技術(shù),你可以很方便的將你的應(yīng)用打包到某一個(gè)指定的環(huán)境(centos/ubuntu/alpine)構(gòu)建特定的鏡像,這個(gè)鏡像可以通過(guò)世界上任意一臺(tái)安裝了docker的服務(wù)器進(jìn)行拉取并成功運(yùn)行,解決了以往應(yīng)用在不同環(huán)境中表現(xiàn)不一致的問(wèn)題。
?
2.1.2?????? 容器和虛擬機(jī)的區(qū)別?
容器和虛擬機(jī)最大的區(qū)別在于容器本身是依賴于linux操作系統(tǒng)的的半獨(dú)立系統(tǒng)而虛擬機(jī)則是擁有獨(dú)立操作系統(tǒng)的沙箱。容器又在此的基礎(chǔ)上提供了進(jìn)程級(jí)的隔離和文件數(shù)據(jù)隔離,基本做到了虛擬機(jī)的體驗(yàn)而資源占用又比虛擬機(jī)少了很多。
?
2.1.3?????? 鏡像/容器/自動(dòng)化構(gòu)建
2.1.3.1?? 容器
容器就是docker中的獨(dú)立最小化單元,是一個(gè)運(yùn)行起來(lái)的鏡像。內(nèi)部包含一個(gè)操作系統(tǒng)+環(huán)境+應(yīng)用程序。比如(centos+jvm+spring boot)/又或者(Ubuntu+python+flaskwebapp)。雖然容器本身對(duì)應(yīng)用并未有安裝限制,但實(shí)際開(kāi)發(fā)時(shí)必須根據(jù)關(guān)注點(diǎn)分離的原則一個(gè)容器只運(yùn)行1個(gè)應(yīng)用。
?
2.1.3.2?? 鏡像
鏡像就是容器的原始文件。當(dāng)我們通過(guò)命令構(gòu)造一個(gè)鏡像后,可以通過(guò)run很方便的把這個(gè)鏡像啟動(dòng)成一個(gè)或一組容器(集群)。有點(diǎn)類似于編程中的類定義文件和運(yùn)行時(shí)的類實(shí)例,一個(gè)類定義文件在運(yùn)行時(shí)可以創(chuàng)建1個(gè)或多個(gè)內(nèi)存中運(yùn)行的實(shí)例,由應(yīng)用來(lái)管理它的生命周期。我們也可以通過(guò)容器快照的方式將某個(gè)容器在某個(gè)時(shí)間點(diǎn)的快照導(dǎo)出成鏡像。該鏡像會(huì)保留容器快照時(shí)的所有狀態(tài)。
?
2.1.3.3?? 自動(dòng)化構(gòu)建
容器可以通過(guò)docker build和docker compose的方式進(jìn)行自動(dòng)化構(gòu)建。前者主要通過(guò)dockerfile的形式將本地的應(yīng)用配合倉(cāng)庫(kù)中的鏡像進(jìn)行一組打包操作形成一個(gè)鏡像。后者則可以直接通過(guò)調(diào)用多個(gè)dockerfile/命令的方式啟動(dòng)一組鏡像(比如一個(gè)微服務(wù)項(xiàng)目含有多個(gè)應(yīng)用。可以通過(guò)此方式一次性全部運(yùn)行起來(lái))
?
2.1.4?????? 鏡像倉(cāng)庫(kù)/市場(chǎng)
?鏡像倉(cāng)庫(kù)/市場(chǎng)就是存放鏡像的云平臺(tái),docker官方提供了(https://hub.docker.com)作為鏡像市場(chǎng)可以免費(fèi)(2018.11)上傳您的本地倉(cāng)庫(kù)中的鏡像,但是由于國(guó)內(nèi)已知的原因,還是推薦使用國(guó)內(nèi)云提供商提供的免費(fèi)(2018.11)鏡像市場(chǎng)(https://www.aliyun.com/product/acr?utm_co
ntent=se_1000088670)或者私有化部署自己的鏡像倉(cāng)庫(kù)(https://www.cn
blogs.com/Javame/p/7389093.html)。
?
2.1.5?????? 容器編排
Docker本身提供了基于shell的方式對(duì)單個(gè)服務(wù)器的容器集合進(jìn)行簡(jiǎn)單的管理,但是在實(shí)際的生產(chǎn)過(guò)程中,我們依然需要更加強(qiáng)大的集中式管理工具來(lái)管理我們跨數(shù)個(gè)服務(wù)的容器集群,k8s就是基于這樣一個(gè)容器管理編排平臺(tái),可以通過(guò)它很方便的管理容器的生命周期,從應(yīng)用創(chuàng)建、部署、擴(kuò)容、更新、調(diào)度均可以在一個(gè)平臺(tái)上完成,而無(wú)需創(chuàng)建復(fù)雜的腳本進(jìn)行運(yùn)維管理。
?
2.2???? 具體實(shí)踐
2.2.1?????? 如何通過(guò)容器進(jìn)行asp.netcore應(yīng)用的發(fā)布?
2.2.1.1?? 準(zhǔn)備工作
2.2.1.1.1??????? 環(huán)境
Linux/windows
Docker/docker for windows
Docker-compose(非必須,需單獨(dú)安裝)
Asp.net core app(我們假設(shè)應(yīng)用已經(jīng)發(fā)布并打包好了)
2.2.1.2?? 發(fā)布流程
打包鏡像一般我們推薦采用dockerfile的形式來(lái)完成。
首先在應(yīng)用所在目錄創(chuàng)建一個(gè)沒(méi)有后綴的名稱叫Dockerfile的文件,用vim或者txt打開(kāi)并編輯它(取決于您采用什么操作系統(tǒng))
命令如下:
#我們需要從本地倉(cāng)庫(kù)拉取一個(gè)基礎(chǔ)鏡像(dotnetcore runtime)
FROM microsoft/dotnet:2.1-runtime
#設(shè)置我們的工作目錄,后面的操作包括文件復(fù)制,命令啟動(dòng)如無(wú)必要均默認(rèn)在該目錄執(zhí)行
WORKDIR /app
#將當(dāng)前dockerfile所在文件夾所有文件復(fù)制到鏡像對(duì)應(yīng)的workdir目錄中
COPY . .
#設(shè)置容器的默認(rèn)啟動(dòng)命令
ENTRYPOINT ["dotnet", "Web.dll"]
?
這樣一個(gè)簡(jiǎn)單的dockerfile就創(chuàng)建好了。接下來(lái)你可以通過(guò)docker build . –t ‘imagename’ 來(lái)構(gòu)建鏡像并通過(guò)docker run 的形式來(lái)運(yùn)行它,或采用docker-compose的方式來(lái)直接構(gòu)建并運(yùn)行它.
?
Docker-compose 方式
在剛才的目錄中可以創(chuàng)建一個(gè)docker-compose.yml文件進(jìn)行容器編排(此處的編排僅僅指打包運(yùn)行一組容器非k8s)
內(nèi)容如下
version: '3.4'
?
services:
???? #名稱,可隨意
? servicename:
#環(huán)境變量,根據(jù)應(yīng)用實(shí)際需要指定傳入
??? environment:
????? - Register_Conn=192.168.0.171:80
#是否默認(rèn)啟動(dòng)
??? restart: always
#指定鏡像名稱,通過(guò)build打包后的鏡像名稱
??? image: servicename:latest
?????????????????????????????????? ?#指定打包,若沒(méi)有則會(huì)直接根據(jù)上一步的鏡像名稱構(gòu)建容器
??? build:
#打包路徑
????? context: .
????? dockerfile: Dockerfile
#構(gòu)建的容器名稱
??? container_name: servicename
#對(duì)外映射端口,左側(cè)是服務(wù)器對(duì)外開(kāi)放的端口,右側(cè)是容器內(nèi)開(kāi)放的端口,假設(shè)我的asp.netcore指定了80端口映射到服務(wù)器提供的8080端口
??? ports:
????? - "8080:80"
通過(guò)簡(jiǎn)單的執(zhí)行 docker-compose up –d –-build 就可以很方便的將應(yīng)用運(yùn)行起來(lái)了。
自動(dòng)發(fā)布
3.1???? 基本概念
3.1.1?????? 什么是CI/CD&CD?
? CI/CD&CD字面意思就是指持續(xù)集成,持續(xù)部署,持續(xù)交付。指出在軟件研發(fā)過(guò)程中需要通過(guò)自動(dòng)化構(gòu)建的方式將產(chǎn)品能夠快速的高質(zhì)量的進(jìn)行交付和迭代,區(qū)別于以往小作坊式的手工方式打包部署,避免了人為原因造成的軟件部署失敗以及提升了部署效率。
3.2???? 具體實(shí)踐
3.2.1?????? Gitlab+gitlabCI+gitlabRunner
軟件安裝
Gitlab:?https://www.cnblogs.com/wenwei-blog/p/5861450.html
gitlab-runner:?https://blog.csdn.net/weiguang1017/article/details/77720778
ci&cd具體落地依賴于版本管控軟件以及自動(dòng)化構(gòu)建工具以及容器技術(shù),我這里采用的例子是gitlab自帶的gitlabci工具。
其發(fā)布流程如下:push代碼到gitlab->gitlab根據(jù)根目錄的.gitlab-ci.yml文件發(fā)布ci命令,若當(dāng)前項(xiàng)目部署了對(duì)應(yīng)的gitlabci,則ci工具會(huì)啟動(dòng)對(duì)應(yīng)的gitlabrunner這個(gè)進(jìn)程開(kāi)始執(zhí)行對(duì)應(yīng)的命令并推送構(gòu)建好的鏡像到遠(yuǎn)程服務(wù)器,大致的流程如下圖:
?
3.2.2?????? 單元測(cè)試(xtest)與質(zhì)量管控(SonarQube)
單元測(cè)試對(duì)于軟件開(kāi)發(fā)來(lái)說(shuō)是必要的,所以需要接入單元測(cè)試。.netcore推薦xunit作為單元測(cè)試工具。
https://www.cnblogs.com/ccccc05/archive/2017/08/01/7266914.html
代碼質(zhì)量管控也是一個(gè)必要的過(guò)程,通過(guò)對(duì)上傳代碼的分析,可以找出一些人為忽略掉的質(zhì)量問(wèn)題,方便后續(xù)版本的改進(jìn)。
http://www.cnblogs.com/qiumingcheng/p/7253917.html
運(yùn)維監(jiān)控
4.1???? 基本概念
4.1.1?????? APM
Apm致力于監(jiān)控管理應(yīng)用軟件性能和可用性,單體應(yīng)用時(shí)代APM的需求并非特別強(qiáng)烈。但是基于微服務(wù)的分布式架構(gòu)下,多個(gè)服務(wù)的性能穩(wěn)定可用必須統(tǒng)一檢測(cè)和管控起來(lái)。
4.1.2?????? 日志與異常
以往的單體應(yīng)用往往采用日志文件或者數(shù)據(jù)庫(kù)記錄的方式來(lái)管理日志和異常(比如知名的log4j),和其他單體應(yīng)用轉(zhuǎn)分布式一樣的問(wèn)題就是每一個(gè)應(yīng)用的異常數(shù)據(jù)和日志都需要統(tǒng)一的進(jìn)行管理
4.2???? 具體實(shí)踐
4.2.1?????? Skywalking+ Elasticsearch + Exceptionless
默認(rèn)已經(jīng)集成到我的微服務(wù)體系里了,可直接運(yùn)行docker版本
4.2.2?????? Elasticsearch+ Logstash + Kibana
JAVA體系下的分布式監(jiān)控與日志框架,可自行了解
原文地址:https://www.cnblogs.com/gmmy/p/10025793.html
.NET社區(qū)新聞,深度好文,歡迎訪問(wèn)公眾號(hào)文章匯總 http://www.csharpkit.com
總結(jié)
以上是生活随笔為你收集整理的.netcore下的微服务、容器、运维、自动化发布的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: C#如何安全、高效地玩转任何种类的内存之
- 下一篇: Docker最全教程——数据库容器化(十