本文來自twt企業(yè)IT社區(qū)，作者/JanXC。
1、單體應用
傳統(tǒng)應用系統(tǒng)多為單體應用、經(jīng)典三層架構(gòu)部署：“應用-數(shù)據(jù)庫-中間件”，關(guān)于該業(yè)務領(lǐng)域的功能實現(xiàn)全部在一個軟件工程中進行開發(fā)，集成發(fā)布打成一個程序包更新，其主要優(yōu)點為：
（1）系統(tǒng)整體架構(gòu)簡潔清晰，測試、部署及運維比較簡便，中小型項目開發(fā)快捷；
（2）資源占用較低，不需要分布式開銷；
單體由于將所有功能模塊耦合在一起，導致其存在如下缺點：
（1）系統(tǒng)耦合度高，容錯能力低，小的問題可能導致整體的不可用；
（2）開發(fā)周期長、程序代碼冗腫，調(diào)試復雜、啟動時間慢；
（3）Bug修復成本高，每一次線上Bug修復需要全局替換、發(fā)布；
（4）擴展性差，應對高并發(fā)、高吞吐能力差；
（5）交付周期長，所有功能一起構(gòu)建、一起部署、一起發(fā)布，代碼集成復雜，出錯率高；
（6）對于大型項目以及需求變化頻次高的系統(tǒng)，重構(gòu)是必然。
綜合單體應用的優(yōu)缺點，其比較適合變化頻次較低的中小型系統(tǒng)，具體表現(xiàn)為用戶量穩(wěn)定、需求變化不大以及整體開發(fā)工程量微小的項目，比較經(jīng)典的系統(tǒng)有：資產(chǎn)管理系統(tǒng)、資質(zhì)管理系統(tǒng)、財務系統(tǒng)、人事系統(tǒng)等。
2、微服務
2.1微服務基礎(chǔ)設(shè)施組件
微服務是云原生的主要技術(shù)內(nèi)容之一，是云上應用的主流架構(gòu)，同時也是應用系統(tǒng)及數(shù)據(jù)適應云平臺的最佳選擇。移動互聯(lián)時代，用戶體量及訪問量幾何式倍增，同時用戶需求和行業(yè)環(huán)境等皆處于快速變化的狀態(tài)，傳統(tǒng)的單體應用受限于其耦合度高、擴展性差、迭代緩慢等缺點已基本不適用與主流應用系統(tǒng)，微服務應運而生。微服務本質(zhì)上是對傳統(tǒng)的單體應用根據(jù)業(yè)務領(lǐng)域和模塊進行劃分、解耦，拆分成一個一個單獨部署、運行的微小應用。
例：單體銷售系統(tǒng)重構(gòu)微服務商城系統(tǒng)
通過拆分單體應用為微服務，實現(xiàn)對業(yè)務系統(tǒng)的充分解耦，可以收獲以下優(yōu)勢：
（1）系統(tǒng)松耦合、服務高內(nèi)聚，代碼聚焦指定業(yè)務功能或需求，專注度高；
（2）系統(tǒng)容錯率高，單服務的故障基本不影響整體系統(tǒng)運行，用戶體驗度高；
（3）易擴展、可前后端分離，應對高并發(fā)、大流量的場景下可以快速擴容服務節(jié)點增大吞吐；
（4）快速迭代、試錯成本低，可以實現(xiàn)對業(yè)務的快速響應。
微服務技術(shù)架構(gòu)包括網(wǎng)關(guān)、注冊中心、配置中心、鏈路監(jiān)控、流量控制等內(nèi)容，整體如下：
圖：微服務框架
（1）服務集群，根據(jù)業(yè)務功能模塊拆分成一個個獨自的項目，每個項目完成獨自的功能，每個項目又稱為獨自的服務，每個服務構(gòu)成了一個服務集群；
（2）注冊中心，應用系統(tǒng)拆分成多個服務之后，每個服務都有獨立的服務信息（IP地址、端口以及功能等），如何讓對方知悉服務信息，需要注冊中心模塊對服務進行整體管理。每個服務在注冊中心中注冊，當用戶進行調(diào)用服務，它首先到注冊中心拉取服務信息再去調(diào)用相對于的服務。
（3）負載均衡，多個服務組成服務集群，在進行服務調(diào)用是通過負載均衡分擔服務調(diào)用流量，實現(xiàn)服務高可用的同時也增加服務的并發(fā)吞吐。
（4）網(wǎng)關(guān)，拆分成多個服務之后，涉及到服務之間的調(diào)用，一個服務調(diào)用了三個服務的模塊，在這個服務里，配置三個調(diào)用地址，看起來是不是很麻煩？所以就出現(xiàn)了網(wǎng)關(guān)，所有的服務調(diào)用都調(diào)用到網(wǎng)關(guān)，然后在網(wǎng)關(guān)里配置路由，進行服務的轉(zhuǎn)發(fā)，類似于代理的作用。當然網(wǎng)關(guān)需要配合注冊中心進行使用，去發(fā)現(xiàn)轉(zhuǎn)發(fā)到哪個服務上去。是為了校驗身份和請求路由，負載均衡。
（5）配置中心，每個服務都會有各自的配置信息，便于統(tǒng)一管理，使用到配置中心，如果想更改服務的配置中心，就在配置中心上進行更改，配置中心會通知相關(guān)的服務實現(xiàn)配置的日更新。
除上述5大基礎(chǔ)組件外，微服務還包括鏈路監(jiān)控、流量控制（限流、熔斷、降級）、日志管理、以及常用的中間件服務（文件、緩存、消息隊列等）和服務網(wǎng)格等。
鏈路監(jiān)控是實現(xiàn)云原生可觀測性的方式之一，應用系統(tǒng)微服務拆分后，服務之間相互調(diào)用，前臺頁面的一個請求往往涉及后端多個服務的調(diào)用實現(xiàn)，復雜的調(diào)用及實現(xiàn)方式造就了一些列的問題，如：問題定位緩慢、故障影響范圍不清以及服務依賴不合理等問題，同時服務調(diào)用的性能和實時容量也存在不清晰的地方，相關(guān)指標如服務吞吐量TPS、服務響應時間、服務調(diào)用失敗率等難以量化。通過全鏈路監(jiān)控從整體維度到局部維度展示各項指標，將跨應用的所有調(diào)用鏈性能信息集中展現(xiàn)，可方便度量整體和局部性能，并且方便找到故障產(chǎn)生的源頭，生產(chǎn)上可極大縮短故障排除時間。有了全鏈路監(jiān)控工具，我們能夠達到：請求鏈路追蹤，故障快速定位：可以通過調(diào)用鏈結(jié)合業(yè)務日志快速定位錯誤信息；可視化：各個階段耗時，進行性能分析；依賴優(yōu)化：各個調(diào)用環(huán)節(jié)的可用性、梳理服務依賴關(guān)系以及優(yōu)化。數(shù)據(jù)分析，優(yōu)化鏈路：可以得到用戶的行為路徑，匯總分析應用在很多業(yè)務場景。
流量控制主要包括流量熔斷、限流、降級，是服務實現(xiàn)高性能、高并發(fā)、高可用的關(guān)鍵手段之一。熔斷是指在服務的依賴調(diào)用中，在服務的依賴調(diào)用中，被調(diào)用方出現(xiàn)故障時，出于自我保護的目的，調(diào)用方會主動停止調(diào)用，并根據(jù)業(yè)務需要進行相應處理。之所以需要熔斷，是因為假定服務A依賴服務B，當服務B處于正常狀態(tài)，整個調(diào)用是健康的，服務A可以得到服務B的正常響應，當服務B出現(xiàn)故障時，比如響應緩慢、超時或是直接宕機，如果服務A繼續(xù)請求服務B，那么服務A的響應時間也會增加，進而導致服務A響應緩慢，如果服務A不進行熔斷處理，服務B的故障會傳導至服務A，最終導致服務A也不可用。限流是針對服務請求數(shù)量的一種自我保護機制，當請求數(shù)量超出服務的處理能力時，會自動丟棄新來的請求。之所以需要限流是因為任何一個系統(tǒng)的處理能力都是有極限的，假定服務A的處理能力為QPS=1000，當QPS<1000時服務A可以提供正常的服務。當QPS>1000時，由于請求量增大，會出現(xiàn)爭搶服務資源的情況（數(shù)據(jù)庫連接、CPU、內(nèi)存等），導致服務A處理緩慢；當QPS繼續(xù)增大時，可能會造成服務A響應更加緩慢甚至奔潰，如果不進行限流控制，服務A始終會面臨著被大流量沖擊的風險，做好系統(tǒng)請求流量的評估，制定合理的限流策略，是我們進行系統(tǒng)高可用保護的重要一步。降級是通過開關(guān)配置將某些不重要的業(yè)務功能屏蔽掉，以提高服務處理能力。在大促場景中經(jīng)常會對某些服務進行降級處理，大促結(jié)束之后再進行復原。之所以需要降級是在不影響業(yè)務核心鏈路的情況下，屏蔽某些不重要的業(yè)務功能，可以節(jié)省系統(tǒng)的處理時間，提供系統(tǒng)的響應能力，在服務器資源固定的前提下處理更多的請求。
日志管理也屬于可觀測性實現(xiàn)方式之一，應用系統(tǒng)服務拆分后，服務、數(shù)據(jù)庫以及中間件等增多，缺乏統(tǒng)一的日志管理將導致問題故障定位復雜、處理時間緩慢等，同時日志缺失、不完整也不符合響應的監(jiān)管要求。日志管理包括兩個方面，一是統(tǒng)一的日志標準，包括日志級別、日志存儲位置、日志存儲周期等，另一個就是統(tǒng)一的技術(shù)架構(gòu)實現(xiàn)日志采集、日志存儲、日志分析、日志展示等。分布式的微服務架構(gòu)，統(tǒng)一的日志管理平臺是必不可少的組件，同時也是提高運維效率和縮短故障定位時間的最佳有效方法之一。
從架構(gòu)的完整性來說，不管是單體應用還是微服務都需要對中間件進展集中管控的，常用的中間件類型有：消息隊列服務、緩存服務、分布式文件服務、任務調(diào)度服務、流程引擎服務、搜索服務等。對于中間件的管理主要包括標準統(tǒng)一的高可用部署、性能優(yōu)化和安全加固、調(diào)用與被調(diào)用的依賴關(guān)系以及配置管理等。
圖：微服務組件全家桶
2.2服務網(wǎng)格
服務網(wǎng)格是用于處理服務間通信的專用基礎(chǔ)設(shè)施層，負責在微服務間進行可靠地請求傳遞。服務網(wǎng)格通常通過一組輕量級網(wǎng)絡(luò)代理來實現(xiàn)，這些代理與應用程序代碼一起部署，而不需要感知應用程序本身。隨著規(guī)模和復雜性的增長，服務網(wǎng)格包含的實現(xiàn)的功能越來越多，它的需求包括服務發(fā)現(xiàn)、負載均衡、故障恢復、指標收集和監(jiān)控以及通常更加復雜的運維需求，例如A/B測試、金絲雀發(fā)布、限流、訪問控制和端到端認證等。其部署結(jié)構(gòu)如下圖所示：
圖：服務網(wǎng)格部署圖
服務網(wǎng)格有如下幾個特點：
●應用程序間通訊的中間層
●輕量級網(wǎng)絡(luò)代理
●應用程序無感知
●解耦應用程序的重試/超時、監(jiān)控、追蹤和服務發(fā)現(xiàn)
如果用一句話來解釋什么是服務網(wǎng)格，可以將它比作是應用程序或者說微服務間的TCP/IP，負責服務之間的網(wǎng)絡(luò)訪問、限流、熔斷和監(jiān)控。對于編寫應用程序來說一般無須關(guān)心TCP/IP這一層（比如通過HTTP協(xié)議的RESTful應用），同樣使用服務網(wǎng)格也就無須關(guān)系服務之間的那些原來是通過應用程序或者其他框架實現(xiàn)的事情，比如Spring Cloud、OSS，現(xiàn)在只要交給服務網(wǎng)格就可以了，從而極大地方便了微服務應用的開發(fā)。
2.3微服務技術(shù)框架
微服務基礎(chǔ)設(shè)施組件眾多，其實現(xiàn)的技術(shù)框架主要有：Dubbo、SpringCloud、SpringCloudAlibaba等。
Dubbo
Apache Dubbo是一款RPC服務開發(fā)框架，用于解決微服務架構(gòu)下的服務治理與通信問題，官方提供了Java、Golang等多語言SDK實現(xiàn)。使用Dubbo開發(fā)的微服務原生具備相互之間的遠程地址發(fā)現(xiàn)與通信能力，利用Dubbo提供的豐富服務治理特性，可以實現(xiàn)諸如服務發(fā)現(xiàn)、負載均衡、流量調(diào)度等服務治理訴求。Dubbo被設(shè)計為高度可擴展，用戶可以方便的實現(xiàn)流量攔截、選址的各種定制邏輯。
在國內(nèi)，Dubbo實質(zhì)上算是第一代微服務的經(jīng)典框架，但自2014年暫停更新后，長期止步于Dubbo2版本直至2017年開源重啟、2021年推出3.0，至此Dubbo3被定義為面向云原生的下一代RPC服務框架。3.0基于Dubbo 2.x演進而來，在保持原有核心功能特性的同時，Dubbo3在易用性、超大規(guī)模微服務實踐、云原生基礎(chǔ)設(shè)施適配、安全性等幾大方向上進行了全面升級。Apache Dubbo總體架構(gòu)能很好的滿足企業(yè)的大規(guī)模微服務實踐，因為它從設(shè)計之初就是為了解決超大規(guī)模微服務集群實踐問題，不論是阿里巴巴還是工商銀行、中國平安、攜程等社區(qū)用戶，它們都通過多年的大規(guī)模生產(chǎn)環(huán)境流量對Dubbo的穩(wěn)定性與性能進行了充分驗證，因此，Dubbo在解決業(yè)務落地與規(guī)?；瘜嵺`方面有以下優(yōu)勢：
開箱即用：易用性高，如Java版本的面向接口代理特性能實現(xiàn)本地透明調(diào)用；功能豐富，基于原生庫或輕量擴展即可實現(xiàn)絕大多數(shù)的微服務治理能力
面向超大規(guī)模微服務集群設(shè)計：極致性能，高性能的RPC通信協(xié)議設(shè)計與實現(xiàn)；橫向可擴展，輕松支持百萬規(guī)模集群實例的地址發(fā)現(xiàn)與流量治理
高度可擴展：調(diào)用過程中對流量及協(xié)議的攔截擴展，如Filter、Router、LB等；微服務治理組件擴展，如Registry、Config Center、Metadata Center等
企業(yè)級微服務治理能力：國內(nèi)公有云廠商支持的事實標準服務框架；多年企業(yè)實踐經(jīng)驗考驗，參考用戶實踐案例
Dubbo核心特性主要有高性能RPC通信協(xié)議、自動服務（地址）發(fā)現(xiàn)、運行態(tài)流量管控、豐富的擴展組件及生態(tài)、面向云原生設(shè)計等。
Spring Cloud
從個人工作經(jīng)歷來看，由于Dubbo的多年停更，給了Spring Cloud在國內(nèi)的快速發(fā)展期，最起碼我所熟悉的3家公司在進行系統(tǒng)重構(gòu)時，皆受限于Dubbo的停更轉(zhuǎn)為使用SpringBoot并逐漸發(fā)展為全套的Spring Cloud，當然Spring Cloud也是非常優(yōu)秀的框架組合。
Spring Cloud是分布式微服務架構(gòu)的一站式解決方案，它提供了一套簡單易用的編程模型，使我們能在Spring Boot的基礎(chǔ)上輕松地實現(xiàn)微服務系統(tǒng)的構(gòu)建。Spring Cloud被稱為構(gòu)建分布式微服務系統(tǒng)的“全家桶”，它并不是某一門技術(shù)，而是一系列微服務解決方案或框架的有序集合。它將市面上成熟的、經(jīng)過驗證的微服務框架整合起來，并通過Spring Boot的思想進行再封裝，屏蔽調(diào)其中復雜的配置和實現(xiàn)原理，最終為開發(fā)人員提供了一套簡單易懂、易部署和易維護的分布式系統(tǒng)開發(fā)工具包。Spring Cloud中包含了spring-cloud-config、spring-cloud-bus等近20個子項目，提供了服務治理、服務網(wǎng)關(guān)、智能路由、負載均衡、斷路器、監(jiān)控跟蹤、分布式消息隊列、配置管理等領(lǐng)域的解決方案。Spring Cloud本身并不是一個拿來即可用的框架，它是一套微服務規(guī)范，共有兩代實現(xiàn)：
Spring Cloud Netflix是Spring Cloud的第一代實現(xiàn)，主要由Eureka、Ribbon、Feign、Hystrix等組件組成；
Spring Cloud Alibaba是Spring Cloud的第二代實現(xiàn)，主要由Nacos、Sentinel、Seata等組件組成。
Spring Cloud的常用組件如下表所示：
Spring Cloud Alibaba
Spring Cloud Alibaba是阿里巴巴結(jié)合自身豐富的微服務實踐而推出的微服務開發(fā)的一站式解決方案，是Spring Cloud第二代實現(xiàn)的主要組成部分。Spring Cloud Alibaba吸收了Spring Cloud Netflix的核心架構(gòu)思想，并進行了高性能改進。自Spring Cloud Netflix進入停更維護后，Spring Cloud Alibaba逐漸代替它成為主流的微服務框架。
Spring Cloud Alibaba包含了多種開發(fā)分布式微服務系統(tǒng)的必需組件：
通過Spring Cloud Alibaba的這些組件，我們只需要添加一些注解和少量配置，就可以將Spring Cloud應用接入阿里微服務解決方案，通過阿里中間件來迅速搭建分布式應用系統(tǒng)。Spring Cloud Alibaba的應用場景如下：大型復雜的系統(tǒng)，例如大型電商系統(tǒng)；高并發(fā)系統(tǒng)，例如大型門戶網(wǎng)站、商品秒殺系統(tǒng)；需求不明確，且變更很快的系統(tǒng)，例如創(chuàng)業(yè)公司業(yè)務系統(tǒng)等。
Spring Cloud兩代實現(xiàn)組件對比如下：
微服務工作流程
以SpringCloud為例，參考CSDN博主（小陳在這兒、weixin_55758948）的一幅圖，簡述微服務的工作流程，具體如下：
各個組件的功能作用如下：
Eureka：各個服務啟動時，Eureka Client都會將服務注冊到Eureka Server，并且Eureka Client還可以反過來從Eureka Server拉取注冊表，從而知道其他服務在哪里
Ribbon：服務間發(fā)起請求的時候，基于Ribbon做負載均衡，從一個服務的多臺機器中選擇一臺
Feign：基于Feign的動態(tài)代理機制，根據(jù)注解和選擇的機器，拼接請求URL地址，發(fā)起請求
Hystrix：發(fā)起請求是通過Hystrix的線程池來走的，不同的服務走不同的線程池，實現(xiàn)了不同服務調(diào)用的隔離，避免了服務雪崩的問題
Zuul：如果前端、移動端要調(diào)用后端系統(tǒng)，統(tǒng)一從Zuul網(wǎng)關(guān)進入，由Zuul網(wǎng)關(guān)轉(zhuǎn)發(fā)請求給對應的服務
其大致步驟為：
（1）步驟一：服務注冊，每個微服務部署有注冊中心的客戶端，將該服務的信息注冊到注冊中心，包括服務名稱、地址、端口號等內(nèi)容；
（2）步驟二：服務發(fā)現(xiàn)，在注冊中心完成服務注冊后，其他服務即可發(fā)現(xiàn)該服務并且根據(jù)需要進行調(diào)用；
（3）步驟三：負載均衡，多個服務組成服務集群，其他服務在進行調(diào)用的時候需要通過負載均衡調(diào)用集群而非單個服務，服務均衡負責同一集群內(nèi)多個服務的調(diào)用策略；
（4）步驟四：服務調(diào)用，即服務在相互間進行調(diào)用；
（5）步驟五：流量控制，服務間調(diào)用存在服務不可用、服務達到瓶頸等問題，需要通過熔斷、限流、降級等措施處理，確保應用整體可用。
（6）步驟六：網(wǎng)關(guān)路由，系外部應用調(diào)用微服務時，通過網(wǎng)關(guān)策略路由至具體服務進行響應。
2.4框架選擇建議
關(guān)于微服務的框架、組件的選擇，建議技術(shù)團隊內(nèi)部進行頭腦風暴式的討論，結(jié)合各種框架、組件的優(yōu)劣勢以及社區(qū)發(fā)展趨勢，選擇最熟悉、最適用的框架及組件。從個人工作經(jīng)歷來看，大致有如下幾個小建議：
（1）配置中心的選擇，建議Nacos Config，一方面是由于SpringCloudConfig過于龐大、復雜，不適用，另一方面Apollo處于停更，相比而言Nacos更好用、更實用；
（2）不選擇停更的組件，如Eureka、Zuul、Hystrix等；
（3）分布式任務調(diào)度建議XXL-Job，比較簡便、穩(wěn)定；
（4）微服務的基礎(chǔ)設(shè)施一定要全，鏈路監(jiān)控、流量管控、服務網(wǎng)格、任務調(diào)度、分布式文件、日志、緩存、消息隊列等，并且集群化高可用部署，預置擴容方案及腳本，確?？呻S時擴展。
由于微服務涉及框架、組件眾多，且多為開源社區(qū)產(chǎn)品，安全問題需要提前考慮，主要有如下幾個方面：
（1）所用組件類型及版本要有清晰的臺賬記錄，一方面用于根據(jù)版本主動查詢、監(jiān)控高危漏洞的情況，另一方面爆出高危漏洞時能夠及時判斷影響范圍；
（2）建立好漏洞管理機制和補丁修復流程，針對不同漏洞制定不同補丁修復策略（修高危、補中危、觀低危）。
2.5微服務的缺點及難題
微服務提高了應用系統(tǒng)高性能、高并發(fā)的能力，并且大幅提高系統(tǒng)吞吐量，也在一定程度上縮短系統(tǒng)開發(fā)周期、提高開發(fā)效率，但其也增加了應用系統(tǒng)的整體復雜度，為開發(fā)、測試、運維及安全等多方面帶來一定的難度，相比單體集中式應用，其缺點主要有如下內(nèi)容：
（1）架構(gòu)層面，增加系統(tǒng)架構(gòu)的復雜度，引入更多的中間件解耦服務之間的共通部分，其服務與中間件以及數(shù)據(jù)庫等的高可用架構(gòu)變得龐大、復雜；從用戶訪問到結(jié)果返回之間的調(diào)用鏈路變長、節(jié)點呈幾何級倍增，雖說微服務提高并發(fā)、提高性能，但是從訪問及調(diào)用鏈路來看，經(jīng)過節(jié)點數(shù)量的增加是為性能帶了了副作用的。
（2）開發(fā)層面，相比單體集中式應用，開發(fā)微服務需要面對復雜的分布式系統(tǒng)，其分布式事務設(shè)計以及數(shù)據(jù)一致性考量需要結(jié)合業(yè)務實際情況進行充分評估。服務之間的調(diào)用需要在開發(fā)層面實現(xiàn)基于消息傳遞或RPC的進程間通信機制，同時需要在代碼層面增加一定的容錯性處理，特別需要考慮有不可靠的網(wǎng)絡(luò)傳輸網(wǎng)絡(luò)延遲、上下游服務延期或不可達類容錯性處理、消息序列化、同步以及異步機制選擇、服務版本化管理、服務差異化的工作負載等內(nèi)容。
（3）測試層面，增加測試的復雜度以及重復測試率，特別是一個服務的修改涉及相關(guān)依賴服務的集成測試、回歸測試，工作量較大，需要自動化測試支持，同時服務量增加、線上Bug增多，測試質(zhì)量需要被高度重視。
（4）運維層面，一是大幅增加部署資源來支持服務、中間件以及數(shù)據(jù)庫等高可用集群運行，資源需求量顯著增加；二是運維復雜度及難度提升，一方面是運維對象倍增管理復雜，容易失控，另一方面是故障定位遲緩，故障解決時間拉長；三是更新發(fā)布量增加，同時發(fā)布失敗率增加。
（5）安全層面，微服務及前后端分離增大網(wǎng)絡(luò)安全攻擊面，同時引入的微服務框架、中間件等多基于開源社區(qū)，風險隱患較高，設(shè)計補丁修復及安全防護成本大幅增加。
總體來說，微服務架構(gòu)一方面給應用系統(tǒng)高并發(fā)、彈性擴展帶來便利可以快速支持業(yè)務變現(xiàn)，另一方面其復雜度增加了技術(shù)及管理成本，需要更多、更專業(yè)的人來使用和維護，對開發(fā)到運維全流程的自動化、智能化高效工作方法提出急迫的新要求。
微服務典型適用于復雜、多變的中大型系統(tǒng)，特別是面向激烈市場競爭的業(yè)務場景，而用戶穩(wěn)定、業(yè)務流程標準清晰、變化甚微的場景下，簡單的單體應用應該更適合。一旦接受微服務，還需要面對如下難點：
（1）服務拆分顆粒度，如何拆分服務是微服務第一難度，過粗或過細的拆分粒度都將導致一系列的問題，所以微服務的第一步需要明確服務拆分的標準及顆粒度。這在實際工作中，一般會按照業(yè)務板塊、業(yè)務線以及業(yè)務模塊進行劃分并且討論、確認，另外服務的拆分標準也并非一成不變，根據(jù)實際業(yè)務變化，服務的拆分及合并也需要動態(tài)跟進。這對架構(gòu)師的業(yè)務理解和業(yè)務規(guī)劃有較高的要求。
（2）微服務基礎(chǔ)設(shè)施，配置中心、鏈路監(jiān)控、容器云平臺以及DevOps工具鏈等，通過微服務基礎(chǔ)設(shè)施推動微服務高效開發(fā)、測試以及運維等，提高微服務管理效率，降低復雜度。
（3）服務依賴，服務內(nèi)高內(nèi)聚、服務之間低耦合是微服務拆分的關(guān)鍵目標，但服務之間的調(diào)用、依賴不可避免，服務之間的調(diào)用及依賴關(guān)系如何管理及展現(xiàn)，某一服務的不可用，其上下游影響如何對全局影響如何，是服務管理難點之一。微服務的全鏈路跟蹤監(jiān)控和云原生可觀測性解決方案可以呈現(xiàn)微服務的全調(diào)研及依賴關(guān)系。
（4）服務標準及服務治理，隨著微服務的開展，服務數(shù)量進一步增加、規(guī)模進一步擴大，為防止服務管理失控產(chǎn)生不可預測的影響，服務標準與服務治理需提前介入，服務標準及治理覆蓋服務全生命周期，包括設(shè)計、開發(fā)、測試、運維、安全等，同時借助統(tǒng)一架構(gòu)和服務基礎(chǔ)設(shè)施進行約束，確保服務安全、可控，并且助力自動化服務管理過程，提高效率和質(zhì)量。
總之，微服務是企業(yè)應用及數(shù)據(jù)變革升級的利器，也是數(shù)字化轉(zhuǎn)型及運營不可或缺的助產(chǎn)工具，企業(yè)云原生更離不開微服務，同時云原生的既要最大化發(fā)揮微服務的價值，也要最大化彌補微服務的缺陷。
