前言

一段時期以來 “微服務(wù)架構(gòu) ”一直是一個熱門詞匯蔫慧，各種技術(shù)類公眾號或架構(gòu)分享會議上，關(guān)于微服務(wù)架構(gòu)的討論和主題也都非常多权薯。對于大部分初創(chuàng)互聯(lián)網(wǎng)公司來說姑躲，早期的單體應(yīng)用結(jié)構(gòu)才是最合適的選擇，只有當業(yè)務(wù)進入快速發(fā)展期盟蚣，在系統(tǒng)壓力黍析、業(yè)務(wù)復(fù)雜度以及人員擴展速度都快速上升的情況下，如何快速屎开、穩(wěn)妥有序的將整個互聯(lián)網(wǎng)軟件系統(tǒng)升級成微服務(wù)架構(gòu)阐枣，以滿足業(yè)務(wù)發(fā)展需要及技術(shù)組織的重新塑造，才是進行微服務(wù)架構(gòu)的最主要的動力奄抽，否則空談微服務(wù)架構(gòu)是沒有意義的蔼两。

而一旦決定將整個應(yīng)用體系按照微服務(wù)架構(gòu)體系進行升級，就需要有組織有計劃的進行業(yè)務(wù)系統(tǒng)逞度、基礎(chǔ)架構(gòu)额划、運維體系等多個方面的升級配套。而另一個比較尷尬的現(xiàn)實是档泽，一般業(yè)務(wù)發(fā)展進入到需要進行微服務(wù)架構(gòu)層面的時候俊戳，業(yè)務(wù)發(fā)展往往又都是非常迅猛的，這種業(yè)務(wù)快速發(fā)展和增長的壓力往往又會給整個技術(shù)團隊帶來非常大的挑戰(zhàn)馆匿，因為此時你需要取舍抑胎，是簡單方案快速支撐呢？還是選擇適當長遠一點的方案渐北？當然這種情況大部分是技術(shù)細節(jié)方面的問題阿逃，掌控的“度”大部分情況是掌握在具體的工程師手中。

而如何整體上確保應(yīng)用體系及組織結(jié)構(gòu)向微服務(wù)時代快速、有序的跨越盆昙，是一件十分考驗團隊能力以及架構(gòu)管理水平的事羽历。能做到80分已然算優(yōu)秀了焊虏，因為這是有其客觀規(guī)律的淡喜！

作者自身親歷了一個快速發(fā)展的互聯(lián)網(wǎng)公司從單體應(yīng)用～以SpringCloud為技術(shù)棧的微服務(wù)架構(gòu)體系的全過程。本文將主要從技術(shù)角度與大家探討如何利用SpringCloud進行微服務(wù)架構(gòu)拆分诵闭，以及在這個過程中一點自己的思考炼团。水平有限，不足之處還請包涵疏尿！

系統(tǒng)架構(gòu)演變概述

在公司業(yè)務(wù)初創(chuàng)時期瘟芝，面對的主要問題是如何將一個想法變成實際的軟件實現(xiàn)，在這個時候整個軟件系統(tǒng)的架構(gòu)并沒有搞得那么復(fù)雜褥琐，為了快速迭代锌俱，整個軟件系統(tǒng)就是由“App+后臺服務(wù)”組成，而后臺服務(wù)也只是從工程角度將應(yīng)用進行Jar包的拆分敌呈。此時軟件系統(tǒng)架構(gòu)如下：

而此時整個軟件系統(tǒng)的功能也比較簡單贸宏，只有基本的用戶、訂單磕洪、支付等功能吭练，并且由于業(yè)務(wù)流程沒有那么復(fù)雜，這些功能基本耦合在一起析显。而隨著App的受歡迎程度（作者所在的公司正好處于互聯(lián)網(wǎng)熱點）鲫咽，所以App下載量在2017年迅猛增長，在線注冊人數(shù)此時也是蹭蹭往上漲谷异。

隨著流量的迅猛增長分尸，此時整個后臺服務(wù)的壓力變得非常大，為了抗住壓力只能不斷的加機器歹嘹，平行擴展后臺服務(wù)節(jié)點箩绍。此時的部署架構(gòu)如下：

通過這種方式，整個軟件系統(tǒng)抗住了一波壓力荞下，然而系統(tǒng)往往還是會偶爾出點事故伶选，特別是因為api中的某個接口性能問題導(dǎo)致整個服務(wù)不可用，因為這些接口都在一個JVM進程中尖昏，雖然此時部署了多個節(jié)點仰税，但因為底層數(shù)據(jù)庫、緩存系統(tǒng)都是一套抽诉，所以還是會出現(xiàn)一掛全掛的情況陨簇。

另一方面，隨著業(yè)務(wù)的快速發(fā)展迹淌，以往相對簡單的功能變得復(fù)雜起來河绽，這些功能除了有用戶看得見的己单、也會包括很多用戶看不見的，就好像百度搜索耙饰，用戶能看見的可能只是一個搜索框纹笼，但是實際上后臺對應(yīng)的服務(wù)可能是成百上千，如有些增長策略相關(guān)的功能：紅包苟跪、分享拉新等廷痘。還有些如廣告推薦相關(guān)的變現(xiàn)功能等。

此外件已，流量/業(yè)務(wù)的增長也意味著團隊人數(shù)的迅速增長笋额，如果此時大家開發(fā)各自的業(yè)務(wù)功能還是用一套服務(wù)代碼，很難想象百十來號人篷扩，在同一個工程在疊加功能會是一個什么樣的場景兄猩。所以如何劃分業(yè)務(wù)邊界、合理的進行團隊配置也是一件十分迫切的事情了鉴未！

為了解決上述問題枢冤，適應(yīng)業(yè)務(wù)、團隊發(fā)展歼狼，架構(gòu)團隊決定進行微服務(wù)拆分掏导。而要實施微服務(wù)架構(gòu)，除了需要合理的劃分業(yè)務(wù)模塊邊界外羽峰，也需要一整套完整的技術(shù)解決方案趟咆。

在技術(shù)方案的選擇上，服務(wù)拆分治理的框架也是有很多梅屉，早期的有如WebService值纱，近期的則有各種Rpc框架（如Dubbo、Thirft坯汤、Grpc）虐唠。而Spring Cloud則是基于Springboot提供的一整套微服務(wù)解決方案，因為技術(shù)棧比較新惰聂，并且各類組件的支撐也非常全面疆偿，所以Spring Cloud就成為了首選。

經(jīng)過一系列的重構(gòu)+擴展搓幌，整個系統(tǒng)架構(gòu)最終形成了以app為中心的一套微服務(wù)軟件系統(tǒng)杆故，結(jié)構(gòu)如下：

到這里，整個軟件系統(tǒng)就基于SpringCloud初步完成了微服務(wù)體系的拆分溉愁。支付处铛、訂單、用戶、廣告等核心功能抽離成獨立的微服務(wù)撤蟆，與此同時各自微服務(wù)對應(yīng)的數(shù)據(jù)庫也按照服務(wù)邊界進行了拆分奕塑。

在完成服務(wù)的拆分以后，原來功能邏輯之間的代碼調(diào)用關(guān)系家肯，轉(zhuǎn)換成了服務(wù)間網(wǎng)絡(luò)的調(diào)用關(guān)系龄砰，而各個微服務(wù)需要根據(jù)各自所承載的功能提供相應(yīng)的服務(wù)，此時服務(wù)如何被其他服務(wù)發(fā)現(xiàn)并調(diào)用息楔，就成了整個微服務(wù)體系中比較關(guān)鍵的部分寝贡，使用過Dubbo框架的同學(xué)知道，在Dubbo中服務(wù)的注冊&發(fā)現(xiàn)是依賴于Zookeeper實現(xiàn)的值依，而在SpringCloud中我們是通過Consul來實現(xiàn)。另外在基于SpringCloud的架構(gòu)體系中碟案，提供了配置中心（ConfigServer）來幫助各個微服務(wù)管理配置文件愿险，而原本的api服務(wù)，隨著各個功能的抽離价说，逐步演變成前置網(wǎng)關(guān)服務(wù)了辆亏。

聊到這里，基于SpringCloud我們進行了微服務(wù)拆分鳖目，而在這個體系結(jié)構(gòu)中扮叨，分別提到了Consul、ConfigServer领迈、網(wǎng)關(guān)服務(wù)這幾個關(guān)鍵組件彻磁，那么這幾個關(guān)鍵組件具體是如何支撐這個龐大的服務(wù)體系的呢？

SpringCloud關(guān)鍵組件

Consul

Consul是一個開源的狸捅，使用go語言開發(fā)的注冊中心服務(wù)衷蜓。它里面內(nèi)置了服務(wù)發(fā)現(xiàn)與注冊框架、分布一致性協(xié)議實現(xiàn)尘喝、健康檢查磁浇、Key/Value存儲、多數(shù)據(jù)中心等多個方案朽褪。在SpringCloud框架中還可以選擇Eurke作為注冊中心置吓，這里之所以選擇Consul主要原因在于Consul對異構(gòu)的服務(wù)的支持,如：grpc服務(wù)。

事實上缔赠，在后續(xù)的系統(tǒng)架構(gòu)演進中衍锚，在某些服務(wù)模塊進一步向子系統(tǒng)化拆分的過程中，就采用了grpc作為子系統(tǒng)服務(wù)間的調(diào)用方式橡淑。例如构拳，支付模塊的繼續(xù)擴張，對支付服務(wù)本身又進行了微服務(wù)架構(gòu)的拆分，此時支付微服務(wù)內(nèi)部就采用了grpc的方式進行調(diào)用置森，而服務(wù)注冊與發(fā)現(xiàn)本身則還是依賴于同一套Consul集群斗埂。

此時的系統(tǒng)架構(gòu)演進如下：

原有微服務(wù)架構(gòu)中的模塊服務(wù)在規(guī)模達到一定程度或復(fù)雜性達到一定程度后，都會朝著獨立的體系發(fā)展凫海，從而將整個微服務(wù)的調(diào)用鏈路變的非常長呛凶，而從Consul的角度看，所有的服務(wù)又都是扁平的行贪。

隨著微服務(wù)規(guī)模的越來越大漾稀，Consul作為整個體系的核心服務(wù)組件，在整個體系中處于關(guān)鍵的位置建瘫，一旦Consul掛掉崭捍，所有的服務(wù)都將停止服務(wù)。那么Consul到底是什么樣服務(wù)啰脚？其容災(zāi)機制又該如何設(shè)計呢殷蛇？

要保證Consul服務(wù)的高可用，在生產(chǎn)環(huán)境Consul應(yīng)該是一個集群（關(guān)于Consul集群的安裝與配置可以參考網(wǎng)絡(luò)資料）橄浓，這是毫無疑問的粒梦。而在Consul集群中，存在兩種角色：Server荸实、Client匀们，這兩種角色與Consul集群上運行的應(yīng)用服務(wù)并沒有什么關(guān)系，只是基于Consul層面的一種角色劃分准给。實際上泄朴，維持整個Consul集群狀態(tài)信息的還是Server節(jié)點，與Dubbo中使用Zookeeper實現(xiàn)注冊中心一樣圆存，Consul集群中的各個Server節(jié)點也需要通過選舉的方式（使用GOSSIP協(xié)議叼旋、Raft一致性算法，這里不做詳細展開沦辙，在后面的文章中可以和大家單獨討論）來選舉整個集群中的Leader節(jié)點來負責處理所有查詢和事務(wù)夫植，并向其他節(jié)點同步狀態(tài)信息。

而Client角色則是相對無狀態(tài)的油讯，只是簡單的代理轉(zhuǎn)發(fā)RPC請求到Server節(jié)點详民，之所以存在Client節(jié)點主要是分擔Server節(jié)點的壓力，作一層緩沖而已陌兑，這主要是因為Server節(jié)點的數(shù)量不宜過多沈跨，因為Server節(jié)點越多也就意味著達成共識的過程越慢，節(jié)點間同步的代價也就越高兔综。對于Server節(jié)點饿凛，一般建議3-5臺狞玛，而Client節(jié)點則沒有數(shù)量的限制，可以根據(jù)實際情況部署數(shù)千或數(shù)萬臺涧窒。事實上心肪，這也只是一種策略，在現(xiàn)實的生產(chǎn)環(huán)境中纠吴，大部分應(yīng)用只需要設(shè)置3～5臺Server節(jié)點就夠了硬鞍，作者所在的公司一套生產(chǎn)集群中的Consul集群的節(jié)點配置就是5個Server節(jié)點，并沒有額外再設(shè)置Client節(jié)點戴已。

另外固该，在Consul集群中還有一個概念是Agent，事實上每個Server或Client都是一個consul agent糖儡，它是運行在Consul集群中每個成員上的一個守護進程伐坏，主要的作用是運行DNS或HTTP接口，并負責運行時檢查和保持服務(wù)信息同步休玩。我們在啟動Consul集群的節(jié)點（Server或Client）時著淆，都是通過consul agent的方式啟動的。例如：

consul agent -server -bootstrap -syslog \
    -ui \
    -data-dir=/opt/consul/data \
    -dns-port=53
    -recursor=10.211.55.3
    -config-dir=/opt/consul/conf \
    -pid-file=/opt/consul/run/consul.pid \
    -client=10.211.55.4 \
    -bind=10.211.55.4 \
    -node=consul-server01 \
    -disable-host-node-id &

以實際的生產(chǎn)環(huán)境為例拴疤，Consul集群的部署結(jié)構(gòu)示意圖如下：

實際生產(chǎn)案例中并沒有設(shè)置Client節(jié)點，而是通過5個Consul Server節(jié)點組成的集群独泞，來服務(wù)整套生產(chǎn)集群的應(yīng)用注冊&發(fā)現(xiàn)呐矾。這里有細節(jié)需要了解下，實際上5個Consul Server節(jié)點的IP地址是不一樣的懦砂，具體的服務(wù)在連接Consul集群進行服務(wù)注冊與查詢時應(yīng)該連接Leader節(jié)點的IP蜒犯，而問題是，如果Leader節(jié)點掛掉了荞膘，相應(yīng)的應(yīng)用服務(wù)節(jié)點罚随，此時如何連接通過Raft選舉產(chǎn)生的新Leader節(jié)點呢？難道手工切換IP不成羽资？

顯然手工切換IP的方式并不靠譜淘菩，而在生產(chǎn)實踐中，Consul集群的各個節(jié)點實際上是在Consul Agent上運行DNS（如啟動參數(shù)中紅色字體部分）屠升，應(yīng)用服務(wù)在連接Consul集群時的IP地址為DNS的IP潮改，DNS會將地址解析映射到Leader節(jié)點對應(yīng)的IP上，如果Leader節(jié)點掛掉腹暖，選舉產(chǎn)生的新Leader節(jié)點會將自己的IP通知DNS服務(wù)汇在，DNS更新映射關(guān)系，這一過程對各應(yīng)用服務(wù)則是透明的脏答。

通過以上分析糕殉，Consul是通過集群設(shè)計亩鬼、Raft選舉算法，Gossip協(xié)議等機制來確保Consul服務(wù)的穩(wěn)定與高可用的阿蝶。如果需要更高的容災(zāi)級別雳锋，也可以通過設(shè)計雙數(shù)據(jù)中心的方式，來異地搭建兩個Consul數(shù)據(jù)中心赡磅，組成一個異地災(zāi)備Consul服務(wù)集群魄缚，只是這樣成本會更高，這就看具體是否真的需要了焚廊。

ConfigServer(配置中心)

配置中心是對微服務(wù)應(yīng)用配置進行管理的服務(wù)虐急，例如數(shù)據(jù)庫的配置、某些外部接口地址的配置等等许溅。在SpringCloud中ConfigServer是獨立的服務(wù)組件寄月，它與Consul一樣也是整個微服務(wù)體系中比較關(guān)鍵的一個組件，所有的微服務(wù)應(yīng)用都需要通過調(diào)用其服務(wù)袒餐，從而獲取應(yīng)用所需的配置信息飞蛹。

隨著微服務(wù)應(yīng)用規(guī)模的擴大，整個ConfigServer節(jié)點的訪問壓力也會逐步增加灸眼，與此同時卧檐，各個微服務(wù)的各類配置也會越來越多，如何管理好這些配置文件以及它們的更新策略（確保不因生產(chǎn)配置隨意改動而造成線上故障風(fēng)險）焰宣，以及搭建高可用的ConfigServer集群霉囚，也是確保微服務(wù)體系穩(wěn)定很重要的一個方面。

在生產(chǎn)實踐中匕积，因為像Consul盈罐、ConfigServer這樣的關(guān)鍵組件，需要搭建獨立的集群闪唆，并且部署在物理機而不是容器里盅粪。在上一節(jié)介紹Consul的時候，我們是獨立搭建了5個Consul Server節(jié)點悄蕾。而ConfigServer因為主要是http配置文件訪問服務(wù)票顾，不涉及節(jié)點選舉、一致性同步這樣的操作笼吟，所以還是按照傳統(tǒng)的方式搭建高可用配置中心库物。具體結(jié)構(gòu)示意圖如下：

我們可以單獨通過git來管理應(yīng)用配置文件，正常來說由ConfigSeever直接通過網(wǎng)絡(luò)拉取git倉庫的配置供服務(wù)獲取就可以了贷帮，這樣只要git倉庫配置更新戚揭，配置中心就能立刻感知到。但是這樣做的不穩(wěn)定之處撵枢，就在于git本身是內(nèi)網(wǎng)開發(fā)用的代碼管理工具民晒，如果讓線上實時服務(wù)直接讀取精居，很容易將git倉庫拉掛了，所以潜必，我們在實際的運維過程中靴姿，是通過git進行配置文件的版本控制，區(qū)分線上分支/master與功能開發(fā)分支/feature磁滚，并且在完成mr后還需要手工（通過發(fā)布平臺觸發(fā)）同步一遍配置佛吓，過程是將新的master分支的配置同步一份到各個configserver節(jié)點所在主機的本地路徑，這樣configserver服務(wù)節(jié)點就可以通過其本地目錄獲取配置文件垂攘，而不用多次調(diào)用網(wǎng)絡(luò)獲取配置文件了维雇。

而另一方面，隨著微服務(wù)越來越多晒他，git倉庫中的配置文件數(shù)量也會越來越多吱型。為了便于配置的管理，我們需要按照一定的組織方式來組織不同應(yīng)用類型的配置陨仅。在早期所有的應(yīng)用因為沒有分類津滞，所以導(dǎo)致上百個微服務(wù)的配置文件放在一個倉庫目錄，這樣一來導(dǎo)致配置文件管理成本增加灼伤，另外一方面也會影響ConfigServer的性能触徐，因為某個微服務(wù)用不到的配置也會被ConfigServer加載。

所以后期的實踐是狐赡，按照配置的層次關(guān)系進行組織锌介，將公司全局的項目配置抽象到頂層，由ConfigServer默認加載猾警，而其他所有的微服務(wù)則按照應(yīng)用類型進行分組（通過git項目空間的方式分組），相同的應(yīng)用放在一個組隆敢，然后這個組下單獨設(shè)立一個名為config的git倉庫來存放這個組下相關(guān)微服務(wù)的配置文件发皿。層次結(jié)構(gòu)如下：

這樣應(yīng)用加載配置的優(yōu)先級就是“本地配置->common配置->組公共配置->項目配置”這樣的順序。例如某服務(wù)A拂蝎，在項目工程的默認配置文件（“bootstrap.yml/application.yml”）中配置了參數(shù)A穴墅，同時也在本地項目配置“application-production.yml”配置了參數(shù)B，而與此同時温自，ConfigServer中的common倉庫下的配置文件“application.yml／application-production.yml”又分別存在參數(shù)C玄货、參數(shù)D，同時有個組叫“pay”悼泌，其下的默認配置文件“application.yml／application-production.yml”存在參數(shù)E松捉、參數(shù)F，具體項目pay-api又存在配置文件“pay-api-production.yml”其覆蓋了common倉庫中參數(shù)C馆里、參數(shù)D的值隘世。那么此時如果該應(yīng)用以“spring.profiles.active=production”的方式啟動可柿，那么其能獲取到的配置參數(shù)（通過鏈接訪問：http://{spring.cloud.config.uri}/pay-api-production.yml）就是A、B丙者、C复斥、D、E械媒、F目锭，其中C、D的參數(shù)值為pay-api-production.yml中最后覆蓋的值纷捞。

而對于ConfigServer服務(wù)本身來說痢虹，需要按照這樣的組織方式進行配置類型匹配，例如上述的例子中兰绣，假設(shè)還存在finance的配置倉庫世分，而pay組下的服務(wù)訪問配置中心的時候，是不需要finance空間下的配置文件的缀辩，所以ConfigServer可以不用加載臭埋。這里就需要在ConfigServer服務(wù)配置中進行一些配置。具體如下：

spring:
  application:
    name: @project.artifactId@
    version: @project.version@
    build: @buildNumber@
    branch: @scmBranch@
  cloud:
    inetutils:
      ignoredInterfaces:
        - docker0
    config:
      server:
        health.enabled: false
        git:
          uri: /opt/repos/config
          searchPaths: 'common,{application}'
          cloneOnStart: true
          repos:
            pay:
                pattern: pay-*
                cloneOnStart: true
                uri: /opt/repos/example/config
                searchPaths: 'common,{application}'
            finance:
                pattern: finance-*
                cloneOnStart: true
                uri: /opt/repos/finance/config
                searchPaths: 'common,{application}'

通過在ConfigServer服務(wù)本身的application.yml本地配置中臀玄，設(shè)置其配置搜索方式瓢阴，來實現(xiàn)這樣的目的。

網(wǎng)關(guān)服務(wù)&服務(wù)熔斷&監(jiān)控

通過上面兩小節(jié)的內(nèi)容健无，我們相對詳細地介紹了基于SpringCloud體系中比較關(guān)鍵的兩個服務(wù)組件荣恐。然而在微服務(wù)架構(gòu)體系中，還有很多關(guān)鍵的問題需要解決累贤，例如叠穆，應(yīng)用服務(wù)在Consul中部署了多個節(jié)點，那么調(diào)用方如何實現(xiàn)負載均衡臼膏？

關(guān)于這個問題硼被，在傳統(tǒng)的架構(gòu)方案中是通過Nginx實現(xiàn)的，但是在前面介紹Consul的時候只提到了Consul的服務(wù)注冊&發(fā)現(xiàn)渗磅、選舉等機制嚷硫，并沒有提到Consul如何在實現(xiàn)服務(wù)調(diào)用的負載均衡。難道基于SpringCloud的微服務(wù)體系中的應(yīng)用服務(wù)都是單節(jié)點在提供服務(wù)始鱼，哪怕即使部署了多個服務(wù)節(jié)點仔掸？事實上，我們在服務(wù)消費方通過@EnableFeignClients注解開啟調(diào)用医清，通過@FeignClient("user")注解進行服務(wù)調(diào)用時起暮，就已經(jīng)實現(xiàn)了負載均衡，為什么呢状勤？因為鞋怀，這個注解默認是會默認開啟Robbin代理的双泪，而Robbin是實現(xiàn)客戶端負載均衡的一個組件，通過從Consul拉取服務(wù)節(jié)點信息密似，從而以輪詢的方式轉(zhuǎn)發(fā)客戶端調(diào)用請求至不同的服務(wù)端節(jié)點來實現(xiàn)負載均衡焙矛。而這一切都是在消費端的進程內(nèi)部通過代碼的方式實現(xiàn)的。這種負載方式寄宿于消費端應(yīng)用服務(wù)上残腌，對消費端存在一定的代碼侵入性村斟，這是為什么后面會出現(xiàn)Service Mesh（服務(wù)網(wǎng)格）概念的原因之一，這里就不展開了抛猫，后面有機會再和大家交流蟆盹。

另一需要解決的關(guān)鍵問題是服務(wù)熔斷、限流等機制的實現(xiàn)闺金，SpringCloud通過集成Netflix的Hystrix框架來提供這種機制的支持逾滥，與負載均衡機制一樣也是在消費端實現(xiàn)。由于篇幅的關(guān)系败匹，這里也不展開了寨昙，在后面的文章中有機會再和大家交流。

此外還有Zuul組件來實現(xiàn)API網(wǎng)關(guān)服務(wù)掀亩，提供路由分發(fā)與過濾相關(guān)的功能舔哪。而其他輔助組件還有諸如Sleuth來實現(xiàn)分布式鏈路追蹤、Bus實現(xiàn)消息總線槽棍、Dashboard實現(xiàn)監(jiān)控儀表盤等捉蚤。由于SpringCloud的開源社區(qū)比較活躍，還有很多新的組件在不斷的被集成進來炼七，感興趣的朋友可以持續(xù)關(guān)注下缆巧！

微服務(wù)之運維形態(tài)

在微服務(wù)體系結(jié)構(gòu)下，隨著服務(wù)數(shù)量大量的增長豌拙，線上的部署&維護的工作量會變得非常大盅蝗，而如果還采用原有的運維模式的話，就能難滿足需要了姆蘸。此時運維團隊需要實施Devops策略，開發(fā)自動化運維發(fā)布平臺芙委，打通產(chǎn)品逞敷、開發(fā)、測試灌侣、運維流程推捐，關(guān)注研發(fā)效能。

另外一方面也需要推進容器化（Docker/Docker Swarm/k8s）策略侧啼，這樣才能快速對服務(wù)節(jié)點進行伸縮牛柒，這也是微服務(wù)體系下的必然要求堪簿。

微服務(wù)泛濫問題

這里還需要注意一個問題，就是實施微服務(wù)架構(gòu)后皮壁，如何在工程上管控微服務(wù)的問題椭更。盲目的進行微服務(wù)的拆分也不是一件很合理的事情，因為這會導(dǎo)致整個服務(wù)調(diào)用鏈路變得深不可測蛾魄，對問題排查造成難度虑瀑，也浪費線上資源。

重構(gòu)問題

在早期單體架構(gòu)方式向微服務(wù)架構(gòu)的轉(zhuǎn)變過程中滴须，重構(gòu)是一個非常好的方式舌狗，也是確保服務(wù)規(guī)范化，業(yè)務(wù)系統(tǒng)應(yīng)用架構(gòu)合理化的很重要的手段扔水。但是痛侍，一般來說，在快速發(fā)展階段也就意味著團隊規(guī)模的迅速增長魔市，短時間內(nèi)如何讓新的團隊有事可做也是一件非持鹘欤考驗管理水平的事情，因為如果招了很多人嘹狞，并且他們之間呈現(xiàn)一種過渡的競爭狀態(tài)的話岂膳，就會出現(xiàn)讓重構(gòu)這件事變得有些功利的情況，從而導(dǎo)致重構(gòu)不徹底磅网、避重就輕谈截，導(dǎo)致表象上看是很高大上的微服務(wù)架構(gòu)，而業(yè)務(wù)系統(tǒng)實際上比較爛的情況涧偷。

另外簸喂，重構(gòu)是在一定階段后作出的重要決策，不僅僅是重新拆分燎潮，也是對業(yè)務(wù)系統(tǒng)的重新塑造喻鳄，所以一定要考慮好應(yīng)用軟件的系統(tǒng)結(jié)構(gòu)以及實施它們所需要付出的成本，切不可盲目确封！