微服務(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)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。