一、前言大家一直都在談?wù)撐⒎?wù)架構(gòu)，園子里面也有很多關(guān)于微服務(wù)的文章，前幾天也有一些園子的朋友問(wèn)我微服務(wù)架構(gòu)的一些技術(shù)，我這里就整理了微服務(wù)架構(gòu)的技術(shù)棧路線圖，這里就分享出來(lái)和大家一起探討學(xué)習(xí)，同時(shí)讓新手對(duì)微服務(wù)相關(guān)技術(shù)有一個(gè)更深入的了解。 二、技術(shù)棧2.1 工欲善其事，必先利其器現(xiàn)在互聯(lián)網(wǎng)盛行的年代，互聯(lián)網(wǎng)產(chǎn)品也層出不窮，受歡迎的互聯(lián)網(wǎng)產(chǎn)品都有一個(gè)比較牛的技術(shù)團(tuán)隊(duì)，我這里分享下.net 微服務(wù)架構(gòu)技術(shù)棧圖如下：
 俗話說(shuō)得好：工欲善其事，必先利其器。一個(gè)優(yōu)秀的工程師應(yīng)該善于使用框架和工具，在微服務(wù)這一塊的技術(shù)選型并非一蹴而就，需要經(jīng)過(guò)日積月累和落地的項(xiàng)目才能完善。
下文我會(huì)一一分享技術(shù)棧中的主要框架和工具的使用場(chǎng)景，這篇文章就不一一分享實(shí)戰(zhàn)例子。 2.2 微服務(wù)微服務(wù)如何“微”？微服務(wù)，當(dāng)然核心是主題是“微”，怎么微呢？應(yīng)該如何微呢？在我剛來(lái)杭州的時(shí)候接觸過(guò)一個(gè)電商系統(tǒng)的單體架構(gòu)，系統(tǒng)比較龐大，結(jié)合了各種電商該擁有的業(yè)務(wù)邏輯和場(chǎng)景，
代碼也比較難于維護(hù)，前前后后接手的人也比較多，代碼耦合度太高，改個(gè)業(yè)務(wù)邏輯基本上是牽一發(fā)而動(dòng)全身，跟我上個(gè)月分享的關(guān)于
Asp.Net Core 中IdentityServer4 授權(quán)中心之應(yīng)用實(shí)戰(zhàn)的文章中的電商系統(tǒng)最初的架構(gòu)圖類似，如下：
那針對(duì)這個(gè)架構(gòu)就有可“微”之談了。 這里針對(duì)該單體架構(gòu)可以做如下幾個(gè)原則上進(jìn)行“微”服務(wù): 根據(jù)業(yè)務(wù)來(lái)進(jìn)行拆分，一個(gè)業(yè)務(wù)一個(gè)服務(wù)原則進(jìn)行拆分，做到通用性業(yè)務(wù)服務(wù)模塊，這樣業(yè)務(wù)之間可以做到高內(nèi)聚低耦合。后面隨意改動(dòng)哪一塊業(yè)務(wù)，只需要去改動(dòng)這一塊的業(yè)務(wù)微服務(wù)即可，其他業(yè)務(wù)不會(huì)受到影響。 一個(gè)業(yè)務(wù)模塊一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)為原則，相互平行的業(yè)務(wù)做到不需要相互依賴調(diào)用。 外層API網(wǎng)關(guān)進(jìn)行業(yè)務(wù)邏輯的整合。 一個(gè)業(yè)務(wù)數(shù)據(jù)庫(kù)一個(gè)微服務(wù)為原則。 結(jié)合分布式服務(wù)，可以快速版本迭代，發(fā)布平滑發(fā)布，不受時(shí)間影響，沒(méi)時(shí)每刻都可以發(fā)布，無(wú)需半夜等到12點(diǎn)進(jìn)行發(fā)布。（比較痛苦的發(fā)布，猶如三日凌空般(有點(diǎn)夸張)，曾經(jīng)有段時(shí)間是每周都有那么幾個(gè)晚上痛苦的發(fā)布，一發(fā)布就可能是凌晨4，5點(diǎn)，很多時(shí)候發(fā)布完，還要經(jīng)過(guò)各種測(cè)試，最后發(fā)現(xiàn)問(wèn)題還得線上改bug，我們回去的時(shí)候別的同事已經(jīng)來(lái)上班了；當(dāng)時(shí)我們的技術(shù)大佬說(shuō)過(guò)這么一句話：“他連續(xù)一周都沒(méi)看到過(guò)他的兒子，回去的時(shí)候，他兒子早就睡著了，起來(lái)上班的時(shí)候，他兒子已經(jīng)去學(xué)校了”，大家一定也有過(guò)這樣的發(fā)布經(jīng)歷。）
按照上面的原則后，原來(lái)的電商單體架構(gòu)微服務(wù)改造升級(jí)后架構(gòu)圖如下：
 架構(gòu)圖粗略的畫了下，能夠表明意思即可，微服務(wù)、Docker、k8s那一塊簡(jiǎn)要的概括，沒(méi)有詳細(xì)畫出具體的圖。 微服務(wù)集群微服務(wù)已經(jīng)“微”好了，那需要一個(gè)服務(wù)發(fā)現(xiàn)的數(shù)據(jù)中心，這里就該用到Consul了，Consul主要用來(lái)注冊(cè)服務(wù)，及服務(wù)發(fā)現(xiàn)，以及服務(wù)的健康檢查，我們可以根據(jù)需要針對(duì)某些業(yè)務(wù)服務(wù)進(jìn)行自動(dòng)擴(kuò)容，添加服務(wù)器及擴(kuò)張服務(wù)集群，一臺(tái)服務(wù)掛了，Consul會(huì)自動(dòng)選擇可用的服務(wù)節(jié)點(diǎn)進(jìn)行連接使用，這樣整體電商系統(tǒng)穩(wěn)定性大大增大。
需要了解Consul更加詳細(xì)的特性和搭建，可以點(diǎn)擊5分鐘看懂微服務(wù)架構(gòu)下的Consul 特性及搭建 一文閱讀。 微服務(wù)如何保證數(shù)據(jù)的一致性以前單體架構(gòu)應(yīng)用，對(duì)于業(yè)務(wù)之間的耦合是通過(guò)事務(wù)保證數(shù)據(jù)的一致性的，那對(duì)于微服務(wù)而言怎么做到數(shù)據(jù)的一致性呢？上面也說(shuō)了，微服務(wù)應(yīng)該做到業(yè)務(wù)之間沒(méi)有依賴關(guān)系，每一個(gè)業(yè)務(wù)都是獨(dú)立的一個(gè)服務(wù)，那這樣怎么保證業(yè)務(wù)與之間的數(shù)據(jù)的一致性也存在很大的一個(gè)問(wèn)題，也是業(yè)界對(duì)微服務(wù)爭(zhēng)議比較大的一個(gè)話題，那到底該如何保證數(shù)據(jù)的一致性？ 在分布式系統(tǒng)架構(gòu)中有一個(gè)CAP理論：任何分布式系統(tǒng)只可同時(shí)滿足一致性（Consistency）、可用性（Availability）、分區(qū)容錯(cuò)性（Partition tolerance）中的兩點(diǎn)，沒(méi)法三者兼顧。對(duì)于分布式系統(tǒng)來(lái)說(shuō)，分區(qū)容錯(cuò)性是基本要求，否則就失去了價(jià)值。因此，就只能在可用性和一致性之間做出選擇。如果選擇提供一致性需要付出在滿足一致性之前阻塞其他并發(fā)訪問(wèn)的代價(jià)。這可能持續(xù)一個(gè)不確定的時(shí)間，尤其是在系統(tǒng)已經(jīng)表現(xiàn)出高延遲時(shí)或者網(wǎng)絡(luò)故障導(dǎo)致失去連接時(shí)。依據(jù)目前的成功經(jīng)驗(yàn)，可用性一般是更好的選擇，但是在服務(wù)和數(shù)據(jù)庫(kù)之間維護(hù)數(shù)據(jù)一致性是非常根本的需求，微服務(wù)架構(gòu)中選擇滿足最終一致性。 最終一致性是指系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過(guò)一段時(shí)間后，最終能夠達(dá)到一致的狀態(tài)。
這里所說(shuō)的一段時(shí)間，也要是用戶可接受范圍內(nèi)的一段時(shí)間。 從一致性的本質(zhì)來(lái)看，就是在一個(gè)業(yè)務(wù)邏輯中包含的所有服務(wù)要么都成功，要么都失敗。那我們又該如何選擇方向，來(lái)保證成功還是保證失敗呢？就是就需要根據(jù)業(yè)務(wù)模式做出選擇。實(shí)現(xiàn)最終一致性有三種模式：可靠事件模式、業(yè)務(wù)補(bǔ)償模式、TCC模式，這里就不再延伸，后面有機(jī)會(huì)再來(lái)分享學(xué)習(xí)。 2.3 微服務(wù)開(kāi)源框架我這里微服務(wù)架構(gòu)使用的是開(kāi)源微服務(wù)框架 core-grpc 開(kāi)源框架源代碼地址：https://github.com/overtly/core-grpc
前面我分享過(guò)一篇關(guān)于 【.net core】電商平臺(tái)升級(jí)之微服務(wù)架構(gòu)應(yīng)用實(shí)戰(zhàn)（core-grpc）
中簡(jiǎn)單描述了微服務(wù)的基本概念和利弊，這里就不再分享，具體應(yīng)用也可以點(diǎn)擊【.net core】電商平臺(tái)升級(jí)之微服務(wù)架構(gòu)應(yīng)用實(shí)戰(zhàn)（core-grpc） 閱讀 2.4 ORM框架微服務(wù)中使用的ORM Dapper ，而使用的的第三方開(kāi)源組件是core-data，開(kāi)源作者對(duì)dapper 進(jìn)行了一次封裝，開(kāi)源框架源代碼地址：https://github.com/overtly/core-data core-data主要優(yōu)勢(shì)：
官方建議使用DDD 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)思想開(kāi)發(fā) 支持多種數(shù)據(jù)庫(kù)，簡(jiǎn)單配置添加鏈接的配置即可 多數(shù)據(jù)庫(kù)的支持 支持分表操作，自定義分表策略的支持 支持表達(dá)式方式編寫，減少寫Sql語(yǔ)句機(jī)械性工作 可對(duì)Dapper 進(jìn)行擴(kuò)展 性能依賴于Dapper 本身的性能，Dapper 本身是輕量級(jí)ORM ，官方測(cè)試性能都強(qiáng)于其他的ORM
2.5 分布式跟蹤系統(tǒng)隨著微服務(wù)架構(gòu)的流行，一些微服務(wù)架構(gòu)下的問(wèn)題也會(huì)越來(lái)越突出，比如一個(gè)請(qǐng)求會(huì)涉及多個(gè)服務(wù)，而服務(wù)本身可能也會(huì)依賴其他服務(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)了。
目前主要的一些 APM 工具有: Cat、Zipkin、Pinpoint、SkyWalking，這里主要介紹 SkyWalking ，它是一款優(yōu)秀的國(guó)產(chǎn) APM 工具，包括了分布式追蹤、性能指標(biāo)分析、應(yīng)用和服務(wù)依賴分析等。 2.6 系統(tǒng)日志集成龐大的系統(tǒng)中離不開(kāi)日志系統(tǒng)，排查問(wèn)題，記錄相關(guān)敏感信息等都需要一個(gè)日志系統(tǒng)，這里選擇使用ExceptionLess 日志系統(tǒng)，日志寫入到ES中，并支持可視化UI進(jìn)行日志管理，查詢，平常遇到問(wèn)題，直接通過(guò)日志管理后臺(tái)進(jìn)行排查。 2.7 消息隊(duì)列消息隊(duì)列中間件是分布式系統(tǒng)中重要的組件，主要解決應(yīng)用耦合，異步消息，流量削鋒等問(wèn)題。實(shí)現(xiàn)高性能、高可用、可伸縮和最終一致性架構(gòu)。使用較多的消息隊(duì)列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ。 2.8 任務(wù)調(diào)度這里主要使用的是Quartz.Net 進(jìn)行作業(yè)任務(wù)調(diào)度，任務(wù)調(diào)用有什么用處呢？，比如我們需要統(tǒng)計(jì)一個(gè)數(shù)據(jù)，但是實(shí)時(shí)統(tǒng)計(jì)需要一大堆的連表查詢，并且比較損耗數(shù)據(jù)庫(kù)的性能，因此可以選擇使用任務(wù)調(diào)度的方案進(jìn)行數(shù)據(jù)統(tǒng)計(jì)作業(yè)，半夜某個(gè)時(shí)間點(diǎn)去統(tǒng)計(jì)前一天的數(shù)據(jù)。 2.9 NoSqlNosql 主要是非關(guān)系型數(shù)據(jù)庫(kù)，比如MongDB、 Redis、Memcache等，可以用來(lái)在API網(wǎng)關(guān)和數(shù)據(jù)庫(kù)層面做一層數(shù)據(jù)緩存，訪問(wèn)一些不是經(jīng)常更新的數(shù)據(jù)，把它緩存起來(lái)，每次網(wǎng)絡(luò)請(qǐng)求過(guò)來(lái)就可以先通過(guò)從分布式緩存中進(jìn)行數(shù)據(jù)讀取，減少對(duì)數(shù)據(jù)庫(kù)的查詢壓力，提高系統(tǒng)的吞吐量。 2.10 可視化數(shù)據(jù)管理及分析（Kibana）Kibana 是為 Elasticsearch設(shè)計(jì)的開(kāi)源分析和可視化平臺(tái)。你可以使用 Kibana 來(lái)搜索，查看存儲(chǔ)在 Elasticsearch 索引中的數(shù)據(jù)并與之交互。你可以很容易實(shí)現(xiàn)高級(jí)的數(shù)據(jù)分析和可視化，以圖標(biāo)的形式展現(xiàn)出來(lái)。
Kibana 的使用場(chǎng)景，應(yīng)該集中在兩方面： 實(shí)時(shí)監(jiān)控
通過(guò) histogram 面板，配合不同條件的多個(gè) queries 可以對(duì)一個(gè)事件走很多個(gè)維度組合出不同的時(shí)間序列走勢(shì)。時(shí)間序列數(shù)據(jù)是最常見(jiàn)的監(jiān)控報(bào)警了。
問(wèn)題分析 關(guān)于 elk 的用途，可以參照其對(duì)應(yīng)的商業(yè)產(chǎn)品 splunk 的場(chǎng)景：使用 Splunk 的意義在于使信息收集和處理智能化。而其操作智能化表現(xiàn)在：
搜索，通過(guò)下鉆數(shù)據(jù)排查問(wèn)題，通過(guò)分析根本原因來(lái)解決問(wèn)題；
實(shí)時(shí)可見(jiàn)性，可以將對(duì)系統(tǒng)的檢測(cè)和警報(bào)結(jié)合在一起，便于跟蹤 SLA 和性能問(wèn)題；
歷史分析，可以從中找出趨勢(shì)和歷史模式，行為基線和閾值，生成一致性報(bào)告。 2.11 PrometheusPrometheus是一套開(kāi)源的系統(tǒng)監(jiān)控報(bào)警框架。Prometheus作為新一代的云原生監(jiān)控系統(tǒng)，相比傳統(tǒng)監(jiān)控監(jiān)控系統(tǒng)（Nagios或者Zabbix）擁有如下優(yōu)點(diǎn)。 優(yōu)勢(shì)好了到了這里，大多已經(jīng)介紹完了，其他幾個(gè)大家都是比較常見(jiàn)常使用的技術(shù)，就不一一介紹了。 2.12 .Net Core 虛擬化.Net Core 新一代的.Net Core 跨平臺(tái)開(kāi)發(fā)框架，可以脫離windows 環(huán)境，搭建在linux等平臺(tái)上，那怎樣搭建呢？當(dāng)然可以使用當(dāng)前比較流行的Docker容器，把.net core 項(xiàng)目虛擬化 搭建在Docker 容器中運(yùn)行，不依賴于任何平臺(tái)和環(huán)境，只需要通過(guò)命令制作好鏡像即可，同時(shí)也可以借助K8s來(lái)進(jìn)行多容器應(yīng)用部署、編排、更新等。 什么是k8s呢？Kubernetes是一個(gè)開(kāi)源的，用于管理云平臺(tái)中多個(gè)主機(jī)上的容器化的應(yīng)用，Kubernetes的目標(biāo)是讓部署容器化的應(yīng)用簡(jiǎn)單并且高效（powerful）,Kubernetes提供了應(yīng)用部署，規(guī)劃，更新，維護(hù)的一種機(jī)制。 Kubernetes一個(gè)核心的特點(diǎn)就是能夠自主的管理容器來(lái)保證云平臺(tái)中的容器按照用戶的期望狀態(tài)運(yùn)行著（比如用戶想讓apache一直運(yùn)行，用戶不需要關(guān)心怎么去做，Kubernetes會(huì)自動(dòng)去監(jiān)控，然后去重啟，新建，總之，讓apache一直提供服務(wù)），管理員可以加載一個(gè)微型服務(wù)，讓規(guī)劃器來(lái)找到合適的位置，同時(shí)，Kubernetes也系統(tǒng)提升工具以及人性化方面，讓用戶能夠方便的部署自己的應(yīng)用（就像canary deployments）。 現(xiàn)在Kubernetes著重于不間斷的服務(wù)狀態(tài)（比如web服務(wù)器或者緩存服務(wù)器）和原生云平臺(tái)應(yīng)用（Nosql）,在不久的將來(lái)會(huì)支持各種生產(chǎn)云平臺(tái)中的各種服務(wù)，例如，分批，工作流，以及傳統(tǒng)數(shù)據(jù)庫(kù)。 在Kubenetes中，所有的容器均在Pod中運(yùn)行,一個(gè)Pod可以承載一個(gè)或者多個(gè)相關(guān)的容器，在后邊的案例中，同一個(gè)Pod中的容器會(huì)部署在同一個(gè)物理機(jī)器上并且能夠共享資源。一個(gè)Pod也可以包含O個(gè)或者多個(gè)磁盤卷組（volumes）,這些卷組將會(huì)以目錄的形式提供給一個(gè)容器，或者被所有Pod中的容器共享，對(duì)于用戶創(chuàng)建的每個(gè)Pod,系統(tǒng)會(huì)自動(dòng)選擇那個(gè)健康并且有足夠容量的機(jī)器，然后創(chuàng)建類似容器的容器,當(dāng)容器創(chuàng)建失敗的時(shí)候，容器會(huì)被node agent自動(dòng)的重啟,這個(gè)node agent叫kubelet,但是，如果是Pod失敗或者機(jī)器，它不會(huì)自動(dòng)的轉(zhuǎn)移并且啟動(dòng)，除非用戶定義了 replication controller。 用戶可以自己創(chuàng)建并管理Pod,Kubernetes將這些操作簡(jiǎn)化為兩個(gè)操作：基于相同的Pod配置文件部署多個(gè)Pod復(fù)制品；創(chuàng)建可替代的Pod當(dāng)一個(gè)Pod掛了或者機(jī)器掛了的時(shí)候。而Kubernetes API中負(fù)責(zé)來(lái)重新啟動(dòng)，遷移等行為的部分叫做“replication controller”，它根據(jù)一個(gè)模板生成了一個(gè)Pod,然后系統(tǒng)就根據(jù)用戶的需求創(chuàng)建了許多冗余，這些冗余的Pod組成了一個(gè)整個(gè)應(yīng)用，或者服務(wù)，或者服務(wù)中的一層。一旦一個(gè)Pod被創(chuàng)建，系統(tǒng)就會(huì)不停的監(jiān)控Pod的健康情況以及Pod所在主機(jī)的健康情況，如果這個(gè)Pod因?yàn)檐浖驋斓袅嘶蛘咚诘臋C(jī)器掛掉了，replication controller 會(huì)自動(dòng)在一個(gè)健康的機(jī)器上創(chuàng)建一個(gè)一摸一樣的Pod,來(lái)維持原來(lái)的Pod冗余狀態(tài)不變，一個(gè)應(yīng)用的多個(gè)Pod可以共享一個(gè)機(jī)器。 我們經(jīng)常需要選中一組Pod，例如，我們要限制一組Pod的某些操作，或者查詢某組Pod的狀態(tài)，作為Kubernetes的基本機(jī)制，用戶可以給Kubernetes Api中的任何對(duì)象貼上一組 key:value的標(biāo)簽，然后，我們就可以通過(guò)標(biāo)簽來(lái)選擇一組相關(guān)的Kubernetes Api 對(duì)象，然后去執(zhí)行一些特定的操作，每個(gè)資源額外擁有一組（很多） keys 和 values,然后外部的工具可以使用這些keys和vlues值進(jìn)行對(duì)象的檢索，這些Map叫做annotations（注釋）。 Kubernetes支持一種特殊的網(wǎng)絡(luò)模型，Kubernetes創(chuàng)建了一個(gè)地址空間，并且不動(dòng)態(tài)的分配端口，它可以允許用戶選擇任何想使用的端口，為了實(shí)現(xiàn)這個(gè)功能，它為每個(gè)Pod分配IP地址。 現(xiàn)代互聯(lián)網(wǎng)應(yīng)用一般都會(huì)包含多層服務(wù)構(gòu)成，比如web前臺(tái)空間與用來(lái)存儲(chǔ)鍵值對(duì)的內(nèi)存服務(wù)器以及對(duì)應(yīng)的存儲(chǔ)服務(wù)，為了更好的服務(wù)于這樣的架構(gòu)，Kubernetes提供了服務(wù)的抽象，并提供了固定的IP地址和DNS名稱，而這些與一系列Pod進(jìn)行動(dòng)態(tài)關(guān)聯(lián)，這些都通過(guò)之前提到的標(biāo)簽進(jìn)行關(guān)聯(lián)，所以我們可以關(guān)聯(lián)任何我們想關(guān)聯(lián)的Pod，當(dāng)一個(gè)Pod中的容器訪問(wèn)這個(gè)地址的時(shí)候，這個(gè)請(qǐng)求會(huì)被轉(zhuǎn)發(fā)到本地代理（kube proxy）,每臺(tái)機(jī)器上均有一個(gè)本地代理，然后被轉(zhuǎn)發(fā)到相應(yīng)的后端容器。Kubernetes通過(guò)一種輪訓(xùn)機(jī)制選擇相應(yīng)的后端容器，這些動(dòng)態(tài)的Pod被替換的時(shí)候,Kube proxy時(shí)刻追蹤著，所以，服務(wù)的 IP地址（dns名稱），從來(lái)不變。 所有Kubernetes中的資源，比如Pod,都通過(guò)一個(gè)叫URI的東西來(lái)區(qū)分，這個(gè)URI有一個(gè)UID,URI的重要組成部分是：對(duì)象的類型（比如pod），對(duì)象的名字，對(duì)象的命名空間，對(duì)于特殊的對(duì)象類型，在同一個(gè)命名空間內(nèi)，所有的名字都是不同的，在對(duì)象只提供名稱，不提供命名空間的情況下，這種情況是假定是默認(rèn)的命名空間。UID是時(shí)間和空間上的唯一。 2.13 自動(dòng)化集成部署為什么需要自動(dòng)化集成部署？我從以下幾點(diǎn)來(lái)分析為什么需要自動(dòng)化集成部署： 什么是自動(dòng)化集成部署？通過(guò)jenkins、gitlab、docker等工具，以及依賴事先寫好的腳本監(jiān)聽(tīng)代碼提交動(dòng)態(tài)、自動(dòng)化構(gòu)造項(xiàng)目鏡像、推送鏡像到鏡像倉(cāng)庫(kù)、Docker 拉起鏡像、啟動(dòng)項(xiàng)目等系列自動(dòng)化腳本處理，可以平滑的一臺(tái)一臺(tái)服務(wù)停止并且更新；一切操作無(wú)需人為的干預(yù)，甚至出現(xiàn)問(wèn)題可以一鍵回滾操作。 自動(dòng)化集成部署有哪些優(yōu)勢(shì)一切自動(dòng)化，無(wú)需人為干預(yù)，提高效率，專業(yè)的人做專業(yè)的事情，開(kāi)發(fā)做好開(kāi)發(fā)的事情即可，運(yùn)維做好運(yùn)維的事情。 發(fā)布可追溯 隨時(shí)人為干預(yù)回滾（通過(guò)腳本回顧上一步自動(dòng)化備份的項(xiàng)目鏡像） 平滑發(fā)布，不影響用戶體驗(yàn)，一臺(tái)一臺(tái)服務(wù)器切斷，發(fā)布更新。
三、結(jié)束語(yǔ)今天寫的有點(diǎn)多了，畫了一張圖就停不下來(lái)了，本文分析了.net core 微服務(wù)架構(gòu)中用到的系列技術(shù)使用場(chǎng)景和用途，沒(méi)有一點(diǎn)實(shí)戰(zhàn)性東西，目的是讓小白有一個(gè)明確的技術(shù)方向，進(jìn)一步掌握微服務(wù)架構(gòu)相關(guān)的技術(shù)；也讓自己對(duì)以往的經(jīng)驗(yàn)進(jìn)行梳理和總結(jié)，這樣才能朝著更大的目標(biāo)前進(jìn)。后面我會(huì)持續(xù)給大家?guī)?lái)更多的干貨和實(shí)戰(zhàn)性東西，
|
