上次寫了一篇文章叫Spring Cloud在國內(nèi)中小型公司能用起來嗎?介紹了Spring Cloud是否能在中小公司使用起來，這篇文章是它的姊妹篇。其實我們在這條路上已經(jīng)走了一年多，從16年初到現(xiàn)在。在使用Spring Cloud之前我們對微服務實踐是沒有太多的體會和經(jīng)驗的。從最初的開源軟件云收藏來熟悉Spring Boot，到項目中的慢慢使用，再到最后全面擁抱Spring Cloud。這篇文章就給大家介紹一下我們使用Spring Boot/Cloud一年多的經(jīng)驗。

在開始之前我們先介紹一下幾個概念，什么是微服務，它的特點是什么? Spring Boot/Cloud都做了那些事情？他們?nèi)咧g又有什么聯(lián)系？

技術背景

什么是微服務

微服務的概念源于2014年3月Martin Fowler所寫的一篇文章“Microservices”。

微服務架構(gòu)是一種架構(gòu)模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相溝通（通常是基于HTTP的RESTful API）。每個服務都圍繞著具體業(yè)務進行構(gòu)建，并且能夠被獨立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應盡量避免統(tǒng)一的、集中式的服務管理機制，對具體的一個服務而言，應根據(jù)業(yè)務上下文，選擇合適的語言、工具對其進行構(gòu)建。

微服務是一種架構(gòu)風格，一個大型復雜軟件應用由一個或多個微服務組成。系統(tǒng)中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下，每個任務代表著一個小的業(yè)務能力。

微服務架構(gòu)優(yōu)勢

復雜度可控：在將應用分解的同時，規(guī)避了原本復雜度無止境的積累。每一個微服務專注于單一功能，并通過定義良好的接口清晰表述服務邊界。由于體積小、復雜度低，每個微服務可由一個小規(guī)模開發(fā)團隊完全掌控，易于保持高可維護性和開發(fā)效率。

獨立部署：由于微服務具備獨立的運行進程，所以每個微服務也可以獨立部署。當某個微服務發(fā)生變更時無需編譯、部署整個應用。由微服務組成的應用相當于具備一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時降低對生產(chǎn)環(huán)境所造成的風險，最終縮短應用交付周期。

技術選型靈活：微服務架構(gòu)下，技術選型是去中心化的。每個團隊可以根據(jù)自身服務的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術棧。由于每個微服務相對簡單，故需要對技術棧進行升級時所面臨的風險就較低，甚至完全重構(gòu)一個微服務也是可行的。

容錯：當某一組件發(fā)生故障時，在單一進程的傳統(tǒng)架構(gòu)下，故障很有可能在進程內(nèi)擴散，形成應用全局性的不可用。在微服務架構(gòu)下，故障會被隔離在單個服務中。若設計良好，其他服務可通過重試、平穩(wěn)退化等機制實現(xiàn)應用層面的容錯。

擴展：單塊架構(gòu)應用也可以實現(xiàn)橫向擴展，就是將整個應用完整的復制到不同的節(jié)點。當應用的不同組件在擴展需求上存在差異時，微服務架構(gòu)便體現(xiàn)出其靈活性，因為每個服務可以根據(jù)實際需求獨立進行擴展。

什么是Spring Boot

Spring Boot是由Pivotal團隊提供的全新框架，其設計目的是用來簡化新Spring應用的初始搭建以及開發(fā)過程。該框架使用了特定的方式來進行配置，從而使開發(fā)人員不再需要定義樣板化的配置。用我的話來理解，就是Spring Boot其實不是什么新的框架，它默認配置了很多框架的使用方式，就像maven整合了所有的jar包，Spring Boot整合了所有的框架（不知道這樣比喻是否合適）。

Spring Boot簡化了基于Spring的應用開發(fā)，通過少量的代碼就能創(chuàng)建一個獨立的、產(chǎn)品級別的Spring應用。 Spring Boot為Spring平臺及第三方庫提供開箱即用的設置，這樣你就可以有條不紊地開始。Spring Boot的核心思想就是約定大于配置，多數(shù)Spring Boot應用只需要很少的Spring配置。采用Spring Boot可以大大的簡化你的開發(fā)模式，所有你想集成的常用框架，它都有對應的組件支持。

Spring Cloud都做了哪些事

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發(fā)便利性巧妙地簡化了分布式系統(tǒng)基礎設施的開發(fā)，如服務發(fā)現(xiàn)注冊、配置中心、消息總線、負載均衡、斷路器、數(shù)據(jù)監(jiān)控等，都可以用Spring Boot的開發(fā)風格做到一鍵啟動和部署。Spring并沒有重復制造輪子，它只是將目前各家公司開發(fā)的比較成熟、經(jīng)得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了復雜的配置和實現(xiàn)原理，最終給開發(fā)者留出了一套簡單易懂、易部署和易維護的分布式系統(tǒng)開發(fā)工具包

以下為Spring Cloud的核心功能：

• 分布式/版本化配置
• 服務注冊和發(fā)現(xiàn)
• 路由
• 服務和服務之間的調(diào)用
• 負載均衡
• 斷路器
• 分布式消息傳遞

我們再來看一張圖：

通過這張圖，我們來了解一下各組件配置使用運行流程：

• 1、請求統(tǒng)一通過API網(wǎng)關（Zuul）來訪問內(nèi)部服務.
• 2、網(wǎng)關接收到請求后，從注冊中心（Eureka）獲取可用服務
• 3、由Ribbon進行均衡負載后，分發(fā)到后端具體實例
• 4、微服務之間通過Feign進行通信處理業(yè)務
• 5、Hystrix負責處理服務超時熔斷
• 6、Turbine監(jiān)控服務間的調(diào)用和熔斷相關指標

Spring Cloud體系介紹

上圖只是Spring Cloud體系的一部分，Spring Cloud共集成了19個子項目，里面都包含一個或者多個第三方的組件或者框架！

Spring Cloud 工具框架

1、Spring Cloud Config 配置中心，利用git集中管理程序的配置。?
2、Spring Cloud Netflix 集成眾多Netflix的開源軟件
3、Spring Cloud Bus 消息總線，利用分布式消息將服務和服務實例連接在一起，用于在一個集群中傳播狀態(tài)的變化?
4、Spring Cloud for Cloud Foundry 利用Pivotal Cloudfoundry集成你的應用程序
5、Spring Cloud Cloud Foundry Service Broker 為建立管理云托管服務的服務代理提供了一個起點。
6、Spring Cloud Cluster 基于Zookeeper, Redis, Hazelcast, Consul實現(xiàn)的領導選舉和平民狀態(tài)模式的抽象和實現(xiàn)。
7、Spring Cloud Consul 基于Hashicorp Consul實現(xiàn)的服務發(fā)現(xiàn)和配置管理。
8、Spring Cloud Security 在Zuul代理中為OAuth2 rest客戶端和認證頭轉(zhuǎn)發(fā)提供負載均衡
9、Spring Cloud Sleuth SpringCloud應用的分布式追蹤系統(tǒng)，和Zipkin，HTrace，ELK兼容。
10、Spring Cloud Data Flow 一個云本地程序和操作模型，組成數(shù)據(jù)微服務在一個結(jié)構(gòu)化的平臺上。
11、Spring Cloud Stream 基于Redis,Rabbit,Kafka實現(xiàn)的消息微服務，簡單聲明模型用以在Spring Cloud應用中收發(fā)消息。
12、Spring Cloud Stream App Starters 基于Spring Boot為外部系統(tǒng)提供spring的集成
13、Spring Cloud Task 短生命周期的微服務，為SpringBooot應用簡單聲明添加功能和非功能特性。
14、Spring Cloud Task App Starters
15、Spring Cloud Zookeeper 服務發(fā)現(xiàn)和配置管理基于Apache Zookeeper。
16、Spring Cloud for Amazon Web Services 快速和亞馬遜網(wǎng)絡服務集成。
17、Spring Cloud Connectors 便于PaaS應用在各種平臺上連接到后端像數(shù)據(jù)庫和消息經(jīng)紀服務。
18、Spring Cloud Starters （項目已經(jīng)終止并且在Angel.SR2后的版本和其他項目合并）
19、Spring Cloud CLI 插件用Groovy快速的創(chuàng)建Spring Cloud組件應用。

當然這個數(shù)量還在一直增加…

三者之間的關系

微服務是一種架構(gòu)的理念，提出了微服務的設計原則，從理論為具體的技術落地提供了指導思想。Spring Boot是一套快速配置腳手架，可以基于Spring Boot快速開發(fā)單個微服務；Spring Cloud是一個基于Spring Boot實現(xiàn)的服務治理工具包；Spring Boot專注于快速、方便集成的單個微服務個體，Spring Cloud關注全局的服務治理框架。

Spring Boot/Cloud是微服務實踐的最佳落地方案。

實戰(zhàn)經(jīng)歷

遇到問題，尋找方案

2015年初的時候，因為公司業(yè)務的大量發(fā)展，我們開始對原有的業(yè)務進行拆分，新上的業(yè)務線也全部使用獨立的項目來開發(fā)，項目和項目之間通過http接口進行訪問。15年的業(yè)務發(fā)展非常迅速，項目數(shù)量也就相應急劇擴大，到了15底的時候項目達60多個，當項目數(shù)達到30幾個的時候，其實我們就遇到了問題，經(jīng)常某個項目因為擴展增加了新的IP地址，我們就需要被動的更新好幾個相關的項目。服務越來越多，服務之間的調(diào)用關系也越來越復雜，有時候想畫一張圖來表示項目和項目之間的依賴關系，線條密密麻麻無法看清。網(wǎng)上有一張圖可以表達我們的心情。

這個時候我們就想找一種方案，可以將我們這么多分布式的服務給管理起來，到網(wǎng)上進行了技術調(diào)研。我們發(fā)現(xiàn)有兩款開源軟件比較適合我們，一個是Dubbo，一個是Spring Cloud。

其實剛開始我們是走了一些彎路的。這兩款框架我們當時都不熟悉，當時國內(nèi)使用Spring Cloud進行開發(fā)的企業(yè)非常的少，我在網(wǎng)上也幾乎沒找到太多應用的案例。但是Dubbo當時在國內(nèi)的使用還是挺普遍的，相關的資料各方面都比較完善。因此在公司擴展新業(yè)務線眾籌平臺的時候，技術選型就先定了Dubbo，因為也是全新的業(yè)務沒有什么負擔，這個項目我們大概開發(fā)了六個月投產(chǎn)，上線之初也遇到了一些問題，但最終還比較順利。

在新業(yè)務線選型使用Dubbo的同時，我們也沒有完全放棄Spring Cloud，我們抽出了一兩名開發(fā)人員學習Spring Boot我也參與其中，為了驗證Spring Boot是否可以到達實戰(zhàn)的標準，我們在業(yè)余的時間使用Spring Boot開發(fā)了一款開源軟件云收藏，經(jīng)過這個項目的實戰(zhàn)驗證我們對Spring Boot就有了信心。最重要的是大家體會到使用Spring Boot的各種便利之后，就再也不想使用傳統(tǒng)的方式來進行開發(fā)了。

但是還有一個問題，在選擇了Spring Boot進行新業(yè)務開發(fā)的同時，并沒有解決我們上面的那個問題，服務于服務直接調(diào)用仍然比較復雜和傳統(tǒng)，這時候我們就開始研究Spring Cloud。因為大家在前期對Spring Boot有了足夠的了解，因此學習Sprig Cloud就顯得順風順水了。所以在使用Dubbo半年之后，我們又全面開始擁抱Spring Cloud。

為什么選擇使用Spring Cloud而放棄了Dubbo

可能大家會問，為什么選擇了使用Dubbo之后，而又選擇全面使用Spring Cloud呢？其中有幾個原因：

1）從兩個公司的背景來談：Dubbo，是阿里巴巴服務化治理的核心框架，并被廣泛應用于中國各互聯(lián)網(wǎng)公司；Spring Cloud是大名鼎鼎的Spring家族的產(chǎn)品。阿里巴巴是一個商業(yè)公司，雖然也開源了很多的頂級的項目，但從整體戰(zhàn)略上來講，仍然是服務于自身的業(yè)務為主。Spring專注于企業(yè)級開源框架的研發(fā)，不論是在中國還是在世界上使用都非常廣泛，開發(fā)出通用、開源、穩(wěn)健的開源框架就是他們的主業(yè)。

2）從社區(qū)活躍度這個角度來對比，Dubbo雖然也是一個非常優(yōu)秀的服務治理框架，并且在服務治理、灰度發(fā)布、流量分發(fā)這方面做的比Spring Cloud還好，除過當當網(wǎng)在基礎上增加了rest支持外，已有兩年多的時間幾乎都沒有任何更新了。在使用過程中出現(xiàn)問題，提交到github的Issue也少有回復。

相反Spring Cloud自從發(fā)展到現(xiàn)在，仍然在不斷的高速發(fā)展，從github上提交代碼的頻度和發(fā)布版本的時間間隔就可以看出，現(xiàn)在Spring Cloud即將發(fā)布2.0版本，到了后期會更加完善和穩(wěn)定。

3) 從整個大的平臺架構(gòu)來講，dubbo框架只是專注于服務之間的治理，如果我們需要使用配置中心、分布式跟蹤這些內(nèi)容都需要自己去集成，這樣無形中使用dubbo的難度就會增加。Spring Cloud幾乎考慮了服務治理的方方面面，更有Spring Boot這個大將的支持，開發(fā)起來非常的便利和簡單。

4）從技術發(fā)展的角度來講，Dubbo剛出來的那會技術理念還是非常先進，解決了各大互聯(lián)網(wǎng)公司服務治理的問題，中國的各中小公司也從中受益不少。經(jīng)過了這么多年的發(fā)展，互聯(lián)網(wǎng)行業(yè)也是涌現(xiàn)了更多先進的技術和理念，Dubbo一直停滯不前，自然有些掉隊，有時候我個人也會感到有點可惜，如果Dubbo一直沿著當初的那個路線發(fā)展，并且延伸到周邊，今天可能又是另一番景象了。

Spring 推出Spring Boot/Cloud也是因為自身的很多原因。Spring最初推崇的輕量級框架，隨著不斷的發(fā)展也越來越龐大，隨著集成項目越來越多，配置文件也越來越混亂，慢慢的背離最初的理念。隨著這么多年的發(fā)展，微服務、分布式鏈路跟蹤等更多新的技術理念的出現(xiàn)，Spring急需一款框架來改善以前的開發(fā)模式，因此才會出現(xiàn)Spring Boot/Cloud項目，我們現(xiàn)在訪問Spring官網(wǎng)，會發(fā)現(xiàn)Spring Boot和Spring Cloud已經(jīng)放到首頁最重點突出的三個項目中的前兩個，可見Spring對這兩個框架的重視程度。

總結(jié)一下，dubbo曾經(jīng)確實很牛逼，但是Spring Cloud是站在近些年技術發(fā)展之上進行開發(fā)，因此更具技術代表性。

如何進行微服務架構(gòu)演進

當我們將所有的新業(yè)務都使用Spring Cloud這套架構(gòu)之后，就會出現(xiàn)這樣一個現(xiàn)象，公司的系統(tǒng)被分成了兩部分，一部分是傳統(tǒng)架構(gòu)的項目，一部分是微服務架構(gòu)的項目，如何讓這兩套配合起來使用就成為了關鍵，這時候Spring Cloud里面的一個關鍵組件解決了我們的問題，就是Zuul。在Spring Cloud架構(gòu)體系內(nèi)的所有微服務都通過Zuul來對外提供統(tǒng)一的訪問入口，所有需要和微服務架構(gòu)內(nèi)部服務進行通訊的請求都走統(tǒng)一網(wǎng)關。如下圖：

從上圖可以看出我們對服務進行了分類，有四種：基礎服務、業(yè)務服務、組合服務、前置服務。不同服務遷移的優(yōu)先級不同

• 基礎服務，是一些基礎組件，與具體的業(yè)務無關。比如：短信服務、郵件服務。這里的服務最容易摘出來做微服務，也是我們第一優(yōu)先級分離出來的服務。
• 業(yè)務服務，是一些垂直的業(yè)務系統(tǒng)，只處理單一的業(yè)務類型，比如：風控系統(tǒng)、積分系統(tǒng)、合同系統(tǒng)。這類服務職責比較單一，根據(jù)業(yè)務情況來選擇是否遷移，比如：如果突然有需求對積分系統(tǒng)進行大優(yōu)化，我們就趁機將積分系統(tǒng)進行改造，是我們的第二優(yōu)先級分離出來的服務。
• 前置服務，前置服務一般為服務的接入或者輸出服務，比如網(wǎng)站的前端服務、app的服務接口這類，這是我們第三優(yōu)先級分離出來的服務。
• 組合服務，組合服務就是涉及到了具體的業(yè)務，比如買標過程，需要調(diào)用很多垂直的業(yè)務服務，這類的服務我們一般放到最后再進行微服務化架構(gòu)來改造，因為這類服務最為復雜，除非涉及到大的業(yè)務邏輯變更，我們是不會輕易進行遷移。

在這四類服務之外，新上線的業(yè)務全部使用Sprng Boot/Cloud這套技術棧。就這樣，我們從開源項目云收藏開始，上線幾個Spring Boot項目，到現(xiàn)在公司絕大部分的項目都是在Spring Cloud這個架構(gòu)體系中。

經(jīng)驗和教訓

架構(gòu)演化的步驟

• 在確定使用Spring Boot/Cloud這套技術棧進行微服務改造之前，先梳理平臺的服務，對不同的服務進行分類，以確認演化的節(jié)奏。
• 先讓團隊熟悉Spring Boot技術，并且優(yōu)先在基礎服務上進行技術改造，推動改動后的項目投產(chǎn)上線
• 當團隊熟悉Spring Boot之后，再推進使用Spring Cloud對原有的項目進行改造。
• 在進行微服務改造過程中，優(yōu)先應用于新業(yè)務系統(tǒng)，前期可以只是少量的項目進行了微服務化改造，隨著大家對技術的熟悉度增加，可以加快加大微服務改造的范圍
• 傳統(tǒng)項目和微服務項目共存是一個很常見的情況，除非公司業(yè)務有大的變化，不建議直接遷移核心項目。

服務拆分原則

服務拆分有以下幾個原則和大家分享

橫向拆分。按照不同的業(yè)務域進行拆分，例如訂單、營銷、風控、積分資源等。形成獨立的業(yè)務領域微服務集群。

縱向拆分。把一個業(yè)務功能里的不同模塊或者組件進行拆分。例如把公共組件拆分成獨立的原子服務，下沉到底層，形成相對獨立的原子服務層。這樣一縱一橫，就可以實現(xiàn)業(yè)務的服務化拆分。

要做好微服務的分層：梳理和抽取核心應用、公共應用，作為獨立的服務下沉到核心和公共能力層，逐漸形成穩(wěn)定的服務中心，使前端應用能更快速的響應多變的市場需求

服務拆分是越小越好嗎？微服務的大與小是相對的。比如在初期，我們把交易拆分為一個微服務，但是隨著業(yè)務量的增大，可能一個交易系統(tǒng)已經(jīng)慢慢變得很大，并且并發(fā)流量也不小，為了支撐更多的交易量，我會把交易系統(tǒng)，拆分為訂單服務、投標服務、轉(zhuǎn)讓服務等。因此微服務的拆分力度需與具體業(yè)務相結(jié)合，總的原則是服務內(nèi)部高內(nèi)聚，服務之間低耦合。

微服務vs傳統(tǒng)開發(fā)

使用微服務有一段時間了，這種開發(fā)模式和傳統(tǒng)的開發(fā)模式對比，有很大的不同。

• 分工不同，以前我們可能是一個一個模塊，現(xiàn)在可能是一人一個系統(tǒng)。
• 架構(gòu)不同，服務的拆分是一個技術含量很高的問題，拆分是否合理對以后發(fā)展影響巨大。
• 部署方式不同，如果還像以前一樣部署估計累死了，自動化運維不可不上。
• 容災不同，好的微服務可以隔離故障避免服務整體down掉，壞的微服務設計仍然可以因為一個子服務出現(xiàn)問題導致連鎖反應。

給數(shù)據(jù)庫帶來的挑戰(zhàn)

每個微服務都有自己獨立的數(shù)據(jù)庫，那么后臺管理的聯(lián)合查詢怎么處理？這應該是大家會普遍遇到的一個問題，有三種處理方案。

1）嚴格按照微服務的劃分來做，微服務相互獨立，各微服務數(shù)據(jù)庫也獨立，后臺需要展示數(shù)據(jù)時，調(diào)用各微服務的接口來獲取對應的數(shù)據(jù)，再進行數(shù)據(jù)處理后展示出來，這是標準的用法，也是最麻煩的用法。

2) 將業(yè)務高度相關的表放到一個庫中，將業(yè)務關系不是很緊密的表嚴格按照微服務模式來拆分，這樣既可以使用微服務，也避免了數(shù)據(jù)庫分散導致后臺系統(tǒng)統(tǒng)計功能難以實現(xiàn)，是一個折中的方案。

3）數(shù)據(jù)庫嚴格按照微服務的要求來切分，以滿足業(yè)務高并發(fā)，實時或者準實時將各微服務數(shù)據(jù)庫數(shù)據(jù)同步到NoSQL數(shù)據(jù)庫中，在同步的過程中進行數(shù)據(jù)清洗，用來滿足后臺業(yè)務系統(tǒng)的使用，推薦使用MongoDB、HBase等。

三種方案在不同的公司我都使用過，第一種方案適合業(yè)務較為簡單的小公司；第二種方案，適合在原有系統(tǒng)之上，慢慢演化為微服務架構(gòu)的公司；第三種適合大型高并發(fā)的互聯(lián)網(wǎng)公司。

微服務的經(jīng)驗和建議

1、建議盡量不要使用Jsp，頁面開發(fā)推薦使用Thymeleaf。Web項目建議獨立部署Tomcat，不要使用內(nèi)嵌的Tomcat，內(nèi)嵌Tomcat部署Jsp項目會偶現(xiàn)龜速訪問的情況。

2、服務編排是個好東西，主要的作用是減少項目中的相互依賴。比如現(xiàn)在有項目a調(diào)用項目b，項目b調(diào)用項目c…一直到h，是一個調(diào)用鏈，那么項目上線的時候需要先更新最底層的h再更新g…更新c更新b最后是更新項目a。這只是這一個調(diào)用鏈，在復雜的業(yè)務中有非常多的調(diào)用，如果要記住每一個調(diào)用鏈對開發(fā)運維人員來說就是災難。

有這樣一個好辦法可以盡量的減少項目的相互依賴，就是服務編排，一個核心的業(yè)務處理項目，負責和各個微服務打交道。比如之前是a調(diào)用b，b掉用c，c調(diào)用d，現(xiàn)在統(tǒng)一在一個核心項目W中來處理，W服務使用a的時候去調(diào)用b，使用b的時候W去調(diào)用c，舉個例子：在第三方支付業(yè)務中，有一個核心支付項目是服務編排，負責處理支付的業(yè)務邏輯，W項目使用商戶信息的時候就去調(diào)用“商戶系統(tǒng)”，需要校驗設備的時候就去調(diào)用“終端系統(tǒng)”，需要風控的時候就調(diào)用“風控系統(tǒng)”，各個項目需要的依賴參數(shù)都由W來做主控。以后項目部署的時候，只需要最后啟動服務編排項目即可。

3、不要為了追求技術而追求技術，確定進行微服務架構(gòu)改造之前，需要考慮以下幾方面的因素：
1）團隊的技術人員是否已經(jīng)具備相關技術基礎。
2）公司業(yè)務是否適合進行微服務化改造，并不是所有的平臺都適合進行微服務化改造，比如：傳統(tǒng)行業(yè)有很多復雜垂直的業(yè)務系統(tǒng)。
3）Spring Cloud生態(tài)的技術有很多，并不是每一種技術方案都需要用上，適合自己的才是最好的。

總結(jié)

Spring Cloud對于中小型互聯(lián)網(wǎng)公司來說是一種福音，因為這類公司往往沒有實力或者沒有足夠的資金投入去開發(fā)自己的分布式系統(tǒng)基礎設施，使用Spring Cloud一站式解決方案能在從容應對業(yè)務發(fā)展的同時大大減少開發(fā)成本。同時，隨著近幾年微服務架構(gòu)和Docker容器概念的火爆，也會讓Spring Cloud在未來越來越“云”化的軟件開發(fā)風格中立有一席之地，尤其是在目前五花八門的分布式解決方案中提供了標準化的、全站式的技術方案，意義可能會堪比當前Servlet規(guī)范的誕生，有效推進服務端軟件系統(tǒng)技術水平的進步。

總結(jié)

以上是生活随笔為你收集整理的中小型互联网公司微服务实践-经验和教训的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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