建站
咨詢
售后
建站咨詢
新聞中心
在微服務(wù)的落地中，第一步就需要進(jìn)行微服務(wù)的拆分，服務(wù)的拆分很困難也很重要，本文就講講怎么進(jìn)行服務(wù)的拆分。
創(chuàng)新互聯(lián)成都企業(yè)網(wǎng)站建設(shè)服務(wù)，提供成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站網(wǎng)站開發(fā),網(wǎng)站定制,建網(wǎng)站,網(wǎng)站搭建,網(wǎng)站設(shè)計(jì),成都響應(yīng)式網(wǎng)站建設(shè)公司,網(wǎng)頁設(shè)計(jì)師打造企業(yè)風(fēng)格網(wǎng)站,提供周到的售前咨詢和貼心的售后服務(wù)。歡迎咨詢做網(wǎng)站需要多少錢:028-86922220
技術(shù)發(fā)展到現(xiàn)在，還沒有一個(gè)具體的，設(shè)計(jì)完善的標(biāo)準(zhǔn)方法來完成服務(wù)的拆分，服務(wù)的拆分是一門技術(shù)更是一門藝術(shù)。
對于服務(wù)的拆分，有兩種情況 ：
1、從零開始開發(fā)新的產(chǎn)品，采用微服務(wù)架構(gòu)，進(jìn)行服務(wù)拆分。
2、將現(xiàn)有的單體架構(gòu)的產(chǎn)品重構(gòu)成微服務(wù)架構(gòu)，進(jìn)行服務(wù)拆分。
如果做的是 ToB 業(yè)務(wù)，最終在企業(yè)內(nèi)部私有化部署落地，那么在大多數(shù)的場景下，微服務(wù)拆分后系統(tǒng)的復(fù)雜度和引發(fā)的新問題會大于帶來的好處。
隨著業(yè)務(wù)的發(fā)展，產(chǎn)品需要進(jìn)行 SaaS 化改造，團(tuán)隊(duì)也引入多種技術(shù)棧，進(jìn)行微服務(wù)的拆分應(yīng)該就是勢在必行了。所以下面介紹的是怎樣將現(xiàn)有單體架構(gòu)拆分成微服務(wù)。
服務(wù)的拆分不是看代碼量或是工程的大小，而是要根據(jù)當(dāng)前業(yè)務(wù)的情況、團(tuán)隊(duì)的情況綜合考慮，還是拿零代碼平臺作為例子。
零代碼平臺中有菜單、流程、表單、頁面等模型，這些模型各自都能獨(dú)立成一個(gè)服務(wù)，但前期為了快速交付，可以都放到一個(gè)工程中，但在代碼組織和架構(gòu)層面，為了后續(xù)的拆分，可以在邏輯和上進(jìn)行隔離，物理文件可以用目錄來區(qū)分，整體還是在一個(gè)大的工程中，如下圖：
服務(wù)的拆分的一個(gè)最大的作用就是解耦，但并不是說一定要拆開才是解耦，在一個(gè)工程中，合理地使用面向?qū)ο蟮囊恍┰瓌t，比如依賴倒置、接口隔離等，也能做到解耦。
平臺的功能在不斷地迭代，現(xiàn)在需要添加 BI 模塊，整個(gè)架構(gòu)也調(diào)整為支持多租戶模式，同時(shí)也需要開發(fā)應(yīng)用商城，將零代碼平臺推上互聯(lián)網(wǎng)，構(gòu)建一個(gè)應(yīng)用生態(tài)，用戶可以直接安裝應(yīng)用或者將自己的應(yīng)用發(fā)布到應(yīng)用商城中。這里添加的 BI 和應(yīng)用商城就可以作為一個(gè)單獨(dú)的服務(wù)，而原來的整個(gè)零代碼平臺可以先作為一個(gè)大的服務(wù)存在，修改后的架構(gòu)圖如下：
上面的例子是從全局的維度來考慮應(yīng)該怎樣去拆分，不一定對，但以我目前的認(rèn)知和現(xiàn)有的場景來看，我認(rèn)為是適合的。
具體到一個(gè)特定的服務(wù)，最基本的要求是具有能訪問的 API ， 并且可以獨(dú)立部署，至于數(shù)據(jù)庫是獨(dú)立還是跟其他服務(wù)共用，也是需要具體問題具體分析，如果存在較多的跨服務(wù)的查詢操作，建議多服務(wù)共用一個(gè)數(shù)據(jù)庫。
服務(wù)與服務(wù)之間需要做到高內(nèi)聚低耦合，如果因?yàn)槠渌?wù)的變更導(dǎo)致需要頻繁更新你的服務(wù)，或者說你的服務(wù)的一個(gè)小的改動會導(dǎo)致很多其他的服務(wù)要進(jìn)行同步修改，那么說明服務(wù)之間的耦合性太高，拆分了享受不到微服務(wù)帶來的好處，反倒是將缺點(diǎn)無限放大了。所以在拆分服務(wù)時(shí)要遵循兩個(gè)原則：
1、通用功能，使用共享庫，比如工具類，提取成 NuGet 包或者 Maven 包，在服務(wù)中進(jìn)行引用;
2、業(yè)務(wù)相關(guān)的公共部分，使用單獨(dú)的服務(wù)，提供 API 的方式供其他服務(wù)調(diào)用。
每個(gè)服務(wù)都可以使用不同的架構(gòu)和技術(shù)棧來實(shí)現(xiàn)，有一種推薦的做法就是使用六邊形架構(gòu)，六邊形架構(gòu)在一些 DDD 的書籍和微服務(wù)的書籍中都有提到，下面是一張六邊形架構(gòu)的架構(gòu)圖：
六邊形架構(gòu)也稱為端口適配器架構(gòu)，可以替代傳統(tǒng)的三層，解決三層架構(gòu)的一些弊端。端口和適配器都分為入站和出站。
- 入站適配器：通常就是對外的 RestAPI，通過調(diào)用入站端口來處理外部的請求，也可以是消息隊(duì)列的消費(fèi)者，進(jìn)行一些事件的監(jiān)聽，來處理異步業(yè)務(wù)，當(dāng)接收到消息時(shí)也是調(diào)用入站端口來進(jìn)行處理。
- 入站端口：業(yè)務(wù)服務(wù)對外暴露的公有方法。
- 出站適配器：出站適配器實(shí)現(xiàn)出站接口，調(diào)用外部的服務(wù)來實(shí)現(xiàn)一個(gè)完整的業(yè)務(wù)邏輯，出站適配器也可以是消息隊(duì)列的生產(chǎn)者。
- 出站端口：出站端口是一組方法的接口定義，提供一種規(guī)范，供出站適配器來實(shí)現(xiàn)。
舉一個(gè)例子：在零代碼平臺中，表單上拖一個(gè)控件保存后，最后的效果是列表上也會有這一列了，而表單和列表屬于兩個(gè)獨(dú)立的服務(wù)，按照六邊形架構(gòu)，調(diào)用關(guān)系如下圖：
六邊形架構(gòu)一個(gè)最大的好處就是將業(yè)務(wù)邏輯和適配器中包含的展示層和數(shù)據(jù)訪問層的邏輯分離開，實(shí)現(xiàn)了解耦。
學(xué)習(xí)微服務(wù)，我覺得有必要同時(shí)學(xué)習(xí)領(lǐng)域驅(qū)動開發(fā)(DDD)，微服務(wù)是一種架構(gòu)風(fēng)格，DDD 是具體的架構(gòu)設(shè)計(jì)方法，互相配合能夠更好地落地，因?yàn)椋?/p>
1、DDD 中子域和限界上下文的概念可以對應(yīng)到微服務(wù)中的服務(wù)。
2、微服務(wù)中一個(gè)服務(wù)可以由一個(gè)團(tuán)隊(duì)進(jìn)行開發(fā)，DDD 的一個(gè)領(lǐng)域模型也是建議由一個(gè)獨(dú)立的團(tuán)隊(duì)負(fù)責(zé)。
進(jìn)行服務(wù)拆分后，之前在一個(gè)進(jìn)程內(nèi)就能完成的事情，現(xiàn)在需要在進(jìn)程間進(jìn)行通信了，有關(guān)進(jìn)程間通信后面再繼續(xù)分享。
零代碼現(xiàn)在越來越火熱，通過高度的抽象，將基礎(chǔ)設(shè)施、重復(fù)性的工作作為平臺本身的能力提供，讓用戶只用關(guān)注業(yè)務(wù)，這其實(shí)也是另一個(gè)層面的解耦和拆分。
文章標(biāo)題：微服務(wù)：如何拆分服務(wù)？
文章起源：http://www.dlmjj.cn/article/cdjoepi.html
