7000 字 + 21 圖，微服務(wù)架構(gòu)概述
點擊關(guān)注公眾號，Java干貨及時送達??
來源：jianshu.com/p/5b1a83a26f5b
一、前言 二、什么是一體化架構(gòu) 二、什么是微服務(wù)架構(gòu) 三、一體化架構(gòu)的問題 四、認識微服務(wù)小結(jié) 五、直觀體驗一下微服務(wù) 六、微服務(wù)拆分的策略 七、微服務(wù)拆分模式 八、微服務(wù)改造的切入點
一、前言
微服務(wù)（MicroServices）是一種架構(gòu)風(fēng)格，一個大型復(fù)雜軟件應(yīng)用由多個微服務(wù)和前端展示層組成。系統(tǒng)中的各個微服務(wù)可被獨立部署，各個微服務(wù)之間是松耦合的。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個任務(wù)代表著一個小的業(yè)務(wù)能力。以往我們開發(fā)應(yīng)用程序都是單體應(yīng)用（可以理解為一個部署包包含了項目的所有功能），雖然開發(fā)和部署比較方便，但后期隨著業(yè)務(wù)的不斷增加為了能夠達到響應(yīng)業(yè)務(wù)需求，單體應(yīng)用的開發(fā)迭代和性能瓶頸等問題愈發(fā)明顯，微服務(wù)就是解決此問題的有效手段。想要回答為什么要使用微服務(wù)架構(gòu)的問題，首先應(yīng)該了解一體化架構(gòu)。
二、什么是一體化架構(gòu)
一體化架構(gòu)顧名思義，將應(yīng)用各層打成一個包來部署。為了讓代碼正常工作，一體化應(yīng)用的所有組件缺一不可。
以典型的3層傳統(tǒng)web應(yīng)用為例，該應(yīng)用由用戶界面、數(shù)據(jù)庫、服務(wù)器端應(yīng)用組成。這里的服務(wù)器端應(yīng)用被稱為monolith（一體化或者單體），包含表現(xiàn)、業(yè)務(wù)層、數(shù)據(jù)層。所有代碼都存在于同一個代碼庫中。為了讓代碼工作起來，它被部署成為一個單元。任何一個小的改動變化，都需要重新構(gòu)建和部署整個應(yīng)用。
單體應(yīng)用架構(gòu)
二、什么是微服務(wù)架構(gòu)
微服務(wù)架構(gòu)是一種架構(gòu)風(fēng)格，整個應(yīng)用被劃分并設(shè)計為以業(yè)務(wù)域為模型的松散耦合的獨立服務(wù)。微服務(wù)中的“微”非常具有欺騙性，事實上它沒有規(guī)定服務(wù)的規(guī)模有多小或多大。
這里的重點是每個獨立服務(wù)都有一個業(yè)務(wù)邊界，可以獨立開發(fā)、測試、部署、監(jiān)控和擴展，甚至可以用不同的編程語言開發(fā)它們。
微服務(wù)架構(gòu)
在基于微服務(wù)的架構(gòu)中，理想情況下每個組件或服務(wù)都有自己的數(shù)據(jù)庫。沒有集中式數(shù)據(jù)庫，我們可以根據(jù)需要為每個單獨的微服務(wù)使用NoSQL、RDBMS或任何其他數(shù)據(jù)庫，這也是讓微服務(wù)真正獨立的原因之一。
三、一體化架構(gòu)的問題
或者說是微服務(wù)架構(gòu)所解決的問題。
3.1難以擴展
一體化架構(gòu)應(yīng)用只能通過在負載均衡器后面放置整個應(yīng)用程序的多個實例來進行水平擴展。如果應(yīng)用中的特定服務(wù)需要擴展，則沒有簡單的選項。我們需要完整地擴展應(yīng)用程序，這顯然會造成不必要的資源浪費。
相比之下，基于微服務(wù)的應(yīng)用程序允許我們根據(jù)需要獨立擴展單個服務(wù)。在上圖中，如果需要縮放服務(wù)B，則可以有10個實例，同時保持其他實例，并可以根據(jù)需要隨時更改。
3.2交付時間長
一體化架構(gòu)在單個應(yīng)用的任何部分/層中進行的任何更改都需要構(gòu)建和部署整個應(yīng)用程序。個人開發(fā)人員還需要下載整個應(yīng)用程序代碼來修復(fù)和測試，而不僅僅是受影響的模塊，這就影響到了持續(xù)部署的效率。
而在微服務(wù)架構(gòu)中，如果僅在一百個微服務(wù)中的一個中需要改變，則僅構(gòu)建和部署改變的微服務(wù)，沒有必要部署一切。我們甚至可以在短時間內(nèi)多次部署。
3.3應(yīng)用復(fù)雜性
過去，隨著應(yīng)用規(guī)模的增長（功能、功能等），團隊也會相應(yīng)擴張，應(yīng)用很快就就會變得復(fù)雜和交織在一起。隨著不同的團隊不斷修改代碼，維護模塊化結(jié)構(gòu)慢慢變得越來越困難，并慢慢導(dǎo)致像意大利面一樣交織的代碼。這不僅會影響代碼質(zhì)量，還會影響整個組織。
在基于微服務(wù)的應(yīng)用中，每個團隊都在單獨的微服務(wù)上工作，代碼會有序很多。
3.4沒有明確的所有權(quán)
在一體化應(yīng)用中，看起來獨立的團隊實際上并不是獨立的。它們同時在相同的代碼庫上工作，嚴(yán)重依賴于彼此。
在基于微服務(wù)的應(yīng)用中，獨立團隊處理單獨的微服務(wù)。一個團隊將擁有一個完整的微服務(wù)。工作的明確所有權(quán)明確控制服務(wù)的一切，包括開發(fā)、部署和監(jiān)控。
3.5故障級聯(lián)
如果沒有正確設(shè)計，一體化應(yīng)用的一部分失敗可能會級聯(lián)并導(dǎo)致整個系統(tǒng)崩潰。
在基于微服務(wù)的架構(gòu)的情況下，我們可以使用斷路器來避免這種故障。
3.6Dev和Ops之間的墻
開發(fā)團隊通常會進行開發(fā)、測試，一旦部署，就會將維護和支持的所有權(quán)交給運維團隊，應(yīng)用此時與開發(fā)團隊無關(guān)了，而運維團隊需要努力在生產(chǎn)環(huán)境中支持一體化架構(gòu)應(yīng)用。
在基于微服務(wù)的應(yīng)用中，團隊的組織理解為“構(gòu)建它、運行它”，開發(fā)團隊繼續(xù)在生產(chǎn)中擁有該應(yīng)用。
3.7陷入某種技術(shù)/語言
使用一體化架構(gòu)，意味著被某種已實現(xiàn)的技術(shù)/語言鎖定。如果需要更改技術(shù)/語言，則必須重寫整個應(yīng)用程序。
使用微服務(wù)，每個服務(wù)可以根據(jù)需求和業(yè)務(wù)使用不同的技術(shù)或語言實現(xiàn)。任何改變服務(wù)技術(shù)/語言的決定都只需要重寫該特定服務(wù)，因為所有微服務(wù)都是相互獨立的。
3.8支持微服務(wù)的正確工具/技術(shù)的可用性
幾年前，我們還沒有適當(dāng)?shù)墓ぞ吆图夹g(shù)來支持微服務(wù)。但自從Docker容器和云基礎(chǔ)設(shè)施（特別是PaaS）向大眾提供服務(wù)以來，微服務(wù)正在大規(guī)模采用，因為它們提供了我們所需的“自由”，而無需進行傳統(tǒng)的配置程序。
四、認識微服務(wù)小結(jié)
4.1 微服務(wù)架構(gòu)優(yōu)點
每個服務(wù)足夠內(nèi)聚，足夠小，代碼容易理解，開發(fā)效率高 服務(wù)直接可以獨立部署，讓持續(xù)部署成為可能 每個服務(wù)可以各自進行水平和垂直擴展，而且每個服務(wù)可以根 據(jù)需要部署到合適的硬件和軟件上 容易擴大開發(fā)團隊，可以根據(jù)每個組件組織開發(fā)團隊 提高容錯性，一個服務(wù)的問題不會讓整個系統(tǒng)癱瘓 系統(tǒng)不會長期限制在某個技術(shù)棧上 降低成本。可盡量復(fù)用已有功能，避免重復(fù)造輪子?？梢源蟠鬁p少項目建設(shè)過程的調(diào)研、設(shè)計、開發(fā)、測試、運維的成本。 易于開發(fā)與維護：一個微服務(wù)只關(guān)心一個特定的業(yè)務(wù)功能，所以他業(yè)務(wù)清晰，代碼量較少。獨立開發(fā)部署服務(wù)。 局部修改容易，所以開發(fā)上線速度和靈活性 更高的代碼質(zhì)量 獲得圍繞業(yè)務(wù)功能創(chuàng)建/組織的代碼 提高生產(chǎn)力。開發(fā)人員專職自己的微服務(wù)開發(fā)，對業(yè)務(wù)和代碼都熟悉。 更容易擴展 技術(shù)棧不受限：每個服務(wù)可用不同的開發(fā)語言 按需伸縮：可根據(jù)不同的需求，實現(xiàn)細粒度的拓展。 為多端化服務(wù)（多種客戶端，例如：瀏覽器，車載終端，安卓，IOS等等）打下堅實的基礎(chǔ)。 持續(xù)集成和持續(xù)交付的應(yīng)用大大提高生產(chǎn)力。提高開發(fā)人員生產(chǎn)力， 開發(fā)人員只需要將代碼推送到代碼倉庫即可。該代碼將被集成，測試，部署，再次測試，與基礎(chǔ)功能（Maven依賴）合并，經(jīng)過質(zhì)量審查，并準(zhǔn)備以極高的信心進行部署。減少了手動操作的環(huán)節(jié)，極大的提高了重復(fù)工作的效率。
4.2 微服務(wù)的缺點
運維的技術(shù)復(fù)雜度和相應(yīng)的運維成本（測試、變更、部署） 必須建立開發(fā)運維一體化機制Devops 必須有完備的監(jiān)控手段和自動化恢復(fù)手段 分區(qū)數(shù)據(jù)庫可能帶來的業(yè)務(wù)數(shù)據(jù)同步與一致性問題 微服務(wù)的接口將成為變更的敏感位（盡量保持接口的穩(wěn)定性，不能經(jīng)常變化入?yún)⒑统鰠ⅲ?/section> 運維要求高：服務(wù)更多意味著運維的投入，單體應(yīng)用只需保證一個應(yīng)用的正常運行，而在微服務(wù)中，需要保證幾十上百的服務(wù)正常運行與協(xié)作。服務(wù)越小，獨立性更好，但是相應(yīng)的服務(wù)數(shù)量就越多。每個服務(wù)都需要獨立的配置、部署、監(jiān)控、日志收集等，成本呈指數(shù)級增長。需要更高的自動化運維策略。 微服務(wù)應(yīng)用作為分布式系統(tǒng)帶來了復(fù)雜性。當(dāng)應(yīng)用是整體應(yīng)用程序時，模塊之間調(diào)用都在應(yīng)用之內(nèi)，即使進行分布式部署，依然在應(yīng)用內(nèi)調(diào)用。可是微服務(wù)是多個獨立的服務(wù)，當(dāng)進行模塊調(diào)用的時候，分布式將會麻煩。 多個獨立數(shù)據(jù)庫，事務(wù)的實現(xiàn)更具挑戰(zhàn)性。 依賴管理復(fù)雜， 測試微服務(wù)變得復(fù)雜，當(dāng)一個服務(wù)依賴另外一個服務(wù)時，測試時候需要另外一個服務(wù)的支持。
五、直觀體驗一下微服務(wù)
5.1 微服務(wù)功能
該微服務(wù)實現(xiàn)如下功能：為vue開發(fā)的小程序及h5頁面提供數(shù)據(jù)接口(就是HTTP的訪問地址)，可以查詢編程語言的服務(wù)。實現(xiàn)了如下的微服務(wù)接口：
通過篩選條件查詢：https://localhost:8888/v2/vue/api/programLanguage/getByName?language_name=P返回： ["PHP","Python"]無條件的全量查詢：https://localhost:8888/v2/vue/api/programLanguage/getAll返回： ["C","vue","java","PHP","Python","C++"]另外一種條件查詢方式：https://localhost:8888/v2/vue/api/programLanguage/getdetail/C返回： {"laguage_name":"C","star_number":10,"desc":"萬物之源C語言。C語言于1969年至1973年之間由AT&T公司旗下貝爾實驗室創(chuàng)建完成，用于構(gòu)建Unix操作系統(tǒng)。C語言是一種通用型命令式計算機編程語言，其支持結(jié)構(gòu)化編程、詞匯變量范圍與遞歸，同時亦是套能夠預(yù)防各類未預(yù)期操作的靜態(tài)類型系統(tǒng)。其最初構(gòu)建目標(biāo)在于編寫系統(tǒng)軟件。"}
5.2 代碼示例
以第一個接口https://localhost:8888/v2/vue/api/programLanguage/getByName代碼為例。
????@ApiVersion(2)?//?加入接口url的版本控制，http://localhost:8888/v2/vue/api/programLanguage/getByName?language_name=C
????@RequestMapping(value?=?"/programLanguage/getByName")
????public?List?getByName(@RequestParam?String?languageName)?{
????????List?filterList?=?languageList.stream().
??????????????????????????????????filter(s?->?s.toLowerCase().contains(languageName.toLowerCase())).
??????????????????????????????????collect(Collectors.toList());
????????return?filterList;
????}
在IDEA啟動該項目后,瀏覽器訪問地址查看效果。
訪問效果
在Postman中調(diào)用微服務(wù)接口，返回的Json數(shù)據(jù)被格式美化了，更易讀些。
Postman
六、微服務(wù)拆分的策略
6.0 微服務(wù)拆分原則
1、單一職責(zé)、高內(nèi)聚低耦合：微服務(wù)邊界內(nèi)的業(yè)務(wù)能力應(yīng)單一，微服務(wù)之間低耦合度；2、微服務(wù)粒度適中：以完成一個完整的業(yè)務(wù)需求來拆分微服務(wù)，不是越細越好；（1）以業(yè)務(wù)模型切入：以業(yè)務(wù)模型中的業(yè)務(wù)活動為基本單元進行拆分，即微服務(wù)邊界最大不能超過業(yè)務(wù)活動；（2）演進式拆分：在實際應(yīng)用過程中根據(jù)負載情況進行微服務(wù)拆分的細化，實現(xiàn)性能升級；（3）讀寫分離：把負責(zé)產(chǎn)生與維護數(shù)據(jù)的業(yè)務(wù)功能和負責(zé)查詢搜索數(shù)據(jù)的業(yè)務(wù)功能分開。3、避免環(huán)形依賴與雙向依賴：可應(yīng)用服務(wù)上移、服務(wù)下移等手段避免生成環(huán)形依賴，應(yīng)用回調(diào)等手段避免生成雙向依賴；4、考慮團隊結(jié)構(gòu)：以完成一個完整的業(yè)務(wù)邏輯所需求的前、中、后端來拆分，便于開發(fā)團隊分別實現(xiàn)。
6.1 錯誤策略
如果徹底顛覆原有系統(tǒng)，投入巨資啟動一個“更大規(guī)?！钡奈⒎?wù)系統(tǒng)來替換會導(dǎo)致延期（幾年才可能帶來價值）、風(fēng)險（超支，或被取消）。
6.2 正確策略
嘗試改變，而非顛覆。試拆一個小系統(tǒng)--->培養(yǎng)能力，積累經(jīng)驗--->更大規(guī)模的推廣的循序漸進方式進行。
微服務(wù)拆分的核心需求：高內(nèi)聚，低耦合，盡可能的減少微服務(wù)間的調(diào)用，盡可能的減少分布式事務(wù)；微服務(wù)應(yīng)該足夠小，能夠分配一個團隊（5人左右）去實現(xiàn)，但也不能過細。
6.2.1 整體思路
先業(yè)務(wù)分解，再領(lǐng)域建模。
6.2.1.1 圍繞限界上下文邊界
微服務(wù)應(yīng)該按照業(yè)務(wù)能力而不是技術(shù)能力進行邊界劃分。微服務(wù)應(yīng)優(yōu)先以限界上下文邊界進行劃分。需注意：
理想情況下限界上下文與微服務(wù)為1:1 考慮到其他原則和現(xiàn)實約束，實際微服務(wù)的劃分有可能在限界上下文圖的基礎(chǔ)上進行合并。 微服務(wù)拆分的底線是不能打破聚合，打破聚合會破壞事務(wù)一致性和業(yè)務(wù)約束。
6.2.1.2 對齊不同業(yè)務(wù)變化速率/相關(guān)度
微服務(wù)架構(gòu)的目標(biāo)之一是實現(xiàn)獨立的部署和發(fā)布，從而更靈活地響應(yīng)業(yè)務(wù)和需求變化。需要在限界上下文的基礎(chǔ)上，考慮不同業(yè)務(wù)的變化速率，將業(yè)務(wù)速率相近的放入一個微服務(wù)中。需注意：
絕對速率 ：有些業(yè)務(wù)只是建設(shè)階段變更頻率較高，維護期相對穩(wěn)定；有些業(yè)務(wù)在可預(yù)見的將來有持續(xù)需求，變化頻率較高。需要將二者區(qū)分放入不同的微服務(wù)。 相對速率 ：軟件系統(tǒng)的響應(yīng)力最終體現(xiàn)在需求的端到端交付周期。如果兩個業(yè)務(wù)的相關(guān)度比較高，變化速率接近，一個業(yè)務(wù)需求到來總是需要同時修改這兩個上下文。需要將二者放入同一個微服務(wù)。
6.2.1.3 考慮系統(tǒng)非功能性需求
微服務(wù)架構(gòu)的優(yōu)勢之一是能適配系統(tǒng)的彈性伸縮要求，更靈活地適應(yīng)業(yè)務(wù)量的增長。在設(shè)計微服務(wù)邊界時需要考慮非功能性需求：
伸縮性：有些業(yè)務(wù)在容量上有極大的彈性伸縮需求(如秒殺)，需要設(shè)計為獨立微服務(wù) 可用性：有些業(yè)務(wù)在可用性上有極高要求(如交易撮合)，需要設(shè)計為獨立微服務(wù) 安全性：有些業(yè)務(wù)在(數(shù)據(jù))安全性上有獨立的要求，需要設(shè)計為獨立微服務(wù) 其他非功能性需求：微服務(wù)視角主要關(guān)注伸縮性、可用性和安全性，但其他非功能性需求也是設(shè)計一個系統(tǒng)需要考慮的
6.2.1.4 其他設(shè)計約束
復(fù)雜度 微服務(wù)在調(diào)測、部署、運維等方面會帶來額外的復(fù)雜度和開銷。將微服務(wù)粒度拆分過細反而是反模式。需要考慮需要解決問題的復(fù)雜度，將相對簡單的服務(wù)合并在一起。 團隊結(jié)構(gòu) 建議一個微服務(wù)由一個獨立的2 pizza team(7+-2個人)進行端到端的開發(fā)和維護。團隊規(guī)模過大或過小有時也是服務(wù)拆分粒度不合理的跡象。此外需要考慮團隊成員的能力搭配。 技術(shù)異構(gòu) 有些遺留系統(tǒng)，業(yè)務(wù)軟件包(如ERP)或技術(shù)組件(如搜索引擎)形成了天然的服務(wù)邊界，是很難被打破成微服務(wù)。
6.2.1.0 戰(zhàn)略設(shè)計階段詳解
電梯演講的模板中，明確了七個方面，用以引導(dǎo)團隊去思考產(chǎn)品本身核心價值及愿景所在，最后可以匯成一句流暢精干的描述語句。
6.2.1.1 業(yè)務(wù)目標(biāo)梳理
從用戶視角出發(fā)，了解用戶需求，確定如何提供響應(yīng)切實到每一類用戶群的產(chǎn)品與服務(wù)的籌劃。
價值定位畫布價值定位畫布是價值定位設(shè)計里的經(jīng)典實踐，描述了產(chǎn)品提供的價值如何與顧客需求之間建立聯(lián)系，以及為什么顧客要去買你的產(chǎn)品。通過分析用戶工作中的成就和痛點來找到需要提供的服務(wù)，明確產(chǎn)品存在的價值和意義。
價值定位畫布
以內(nèi)部員工的培訓(xùn)系統(tǒng)為例，進行業(yè)務(wù)目標(biāo)梳理。
6.2.1.2 場景梳理方法
是針對核心用戶及頂層服務(wù)的一種定性分析。同時也是從用戶視角對問題域的探索，產(chǎn)出問題域中存在的需要支撐的場景分類及典型場景，用以支撐領(lǐng)域建模階段。
場景梳理步驟步驟1: 選定由價值定位畫布中提煉出的一塊問題域/業(yè)務(wù)；步驟2: 參與者針對所選定的問題域，發(fā)散思考其中存在的各個服務(wù)場景，可以采用貼便簽紙的方式；步驟3: 對發(fā)散所得的服務(wù)場景進行收斂整理，得到場景分類清單。
場景梳理方法
6.2.1.3 流程梳理和領(lǐng)域建模示例
通過對業(yè)務(wù)和問題域進行分析，建立領(lǐng)域模型，向上通過限界上下文指導(dǎo)微服務(wù)的邊界設(shè)計，向下通過聚合指導(dǎo)實體的對象設(shè)計。
領(lǐng)域建模
6.2.1.4 限界上下文設(shè)計示例
6.2.1.5 確定微服務(wù)拆分
圍繞限界上下文調(diào)整。
設(shè)計因素1：圍繞限界上下文邊界， 理想情況下限界上下文與微服務(wù)為1:1， 微服務(wù)拆分的底線是不能打破聚合，打破聚合會破壞事務(wù)一致性和業(yè)務(wù)約束。 設(shè)計因素2：考慮系統(tǒng)非功能性需求：安全性、伸縮性等 設(shè)計因素3：其他設(shè)計約束：復(fù)雜度、團隊結(jié)構(gòu)、技術(shù)異構(gòu)
6.2.1.6 分層模型
分層模型是領(lǐng)域驅(qū)動設(shè)計里分層技術(shù)架構(gòu)的體現(xiàn)。結(jié)合微服務(wù)特點，根據(jù)實際業(yè)務(wù)和技術(shù)情況定義整體架構(gòu)的分層情況，從而降低設(shè)計復(fù)雜性。需要考慮每個具體的微服務(wù)內(nèi)部的分層結(jié)構(gòu)。
6.2.1.7 需求變更
七、微服務(wù)拆分模式
7.1 絞殺模式 （Strangler）
絞殺者模式類似建筑拆遷，在新建筑分階段建設(shè)完成入住后，分步拆除舊建筑物。
“絞殺者模式”是在遺留系統(tǒng)外圍，將新功能用新的方式構(gòu)建為新的服務(wù) 。通過在新的應(yīng)?中實現(xiàn)新特性，保持和現(xiàn)有系統(tǒng)的松耦合，隨著時間的推移，新的服務(wù)逐漸“絞殺”老的系統(tǒng)。以此逐步地替換原有系統(tǒng)。適合于那些老舊龐大難以更改的遺留系統(tǒng)。
“絞殺模式”，有一個別名，叫做“停止挖坑”，意思就是不要在當(dāng)前的系統(tǒng)里繼續(xù)增加功能，而是采用松耦合的方式增加新的功能，使得老的功能慢慢被絞殺掉。這種模式的前提就是要確認遺留系統(tǒng)不再進行功能新增，只做 Bug 修復(fù)和例行維護。這樣帶來的變更風(fēng)險最小，但演進時間較長。
絞殺模式逐步替換老系統(tǒng)
7.2 修繕者模式(Rehab）
修繕者模式類似文物修復(fù)，將存在問題的部分建筑重建或者修復(fù)后，重新加入到原有的建筑中，保持建筑原貌。
“修繕者模式”是在既有系統(tǒng)的基礎(chǔ)上，通過剝離新業(yè)務(wù)和功能，逐步“釋放”現(xiàn)有系統(tǒng)耦合度，解決遺留系統(tǒng)質(zhì)量不穩(wěn)定和 Bug 多的問題。就如修房或修路一樣，將老舊待修繕的部分進行隔離，用新的方式對其進行單獨修復(fù)。修復(fù)的同時，需保證與其他部分仍能協(xié)同功能。修繕模式適用于需求變更頻率不高的存量系統(tǒng)。
一運行時間超過5年的遺留系統(tǒng)，其中某個模塊需要升級，我們單獨把這個模塊微服務(wù)化到新系統(tǒng)，然后老系統(tǒng)開始使用新開發(fā)的微服務(wù)。
另外一個注意點就是：老的應(yīng)用和數(shù)據(jù)庫一起遷移到新的微服務(wù)當(dāng)中去！
修善者模式
八、微服務(wù)改造的切入點
微服務(wù)接口開發(fā)難易程度由低到高:
數(shù)據(jù)源維度
第三方接口-->全新業(yè)務(wù)全新數(shù)據(jù)庫-->老業(yè)務(wù)簡單數(shù)據(jù)庫結(jié)構(gòu)-->老業(yè)務(wù)復(fù)雜數(shù)據(jù)庫結(jié)構(gòu)-->老的第三方封閉系統(tǒng)。
接口類別維度
單一查詢接口-->全新業(yè)務(wù)涉及增刪改查接口-->老業(yè)務(wù)數(shù)據(jù)寫入接口。
2.?45 個 Git 經(jīng)典操作場景，專治不會合代碼
最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點“在看”，關(guān)注公眾號并回復(fù)?Java?領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
PS：因公眾號平臺更改了推送規(guī)則，如果不想錯過內(nèi)容，記得讀完點一下“在看”，加個“星標(biāo)”，這樣每次新文章推送才會第一時間出現(xiàn)在你的訂閱列表里。
點“在看”支持小哈呀，謝謝啦??
