建站
咨詢
售后
建站咨詢
新聞中心
1. 領(lǐng)域驅(qū)動設(shè)計
創(chuàng)新互聯(lián)專注于企業(yè)網(wǎng)絡(luò)營銷推廣、網(wǎng)站重做改版、杜爾伯特網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、H5場景定制、購物商城網(wǎng)站建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為杜爾伯特等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
微服務(wù)開發(fā)的首要挑戰(zhàn)：
把大的、復(fù)雜的應(yīng)用拆分為小的、自治的、可獨立部署的模塊。
如果沒有正確的拆分，那么結(jié)果就是一堆漿糊，有著單體結(jié)構(gòu)的缺點，和微服務(wù)結(jié)構(gòu)的復(fù)雜度，可以稱之為分布式單體。
幸運的是，Eric Evans 為領(lǐng)域驅(qū)動設(shè)計提出了大量的最佳實踐和經(jīng)驗技巧，有3個核心思維：
- 開發(fā)團(tuán)隊要和業(yè)務(wù)部門、業(yè)務(wù)領(lǐng)域?qū)＜揖o密合作。
- 架構(gòu)師、開發(fā)人員、領(lǐng)域?qū)＜覒?yīng)該先做出戰(zhàn)略設(shè)計：找出邊界上下文、核心域、子域、上下文映射關(guān)系。
- 架構(gòu)師、開發(fā)人員根據(jù)戰(zhàn)略設(shè)計梳理出一套核心構(gòu)造塊：實體、值對象、聚合等等。
把一個大型系統(tǒng)劃分為核心域、子域，再把核心域、子域映射為微服務(wù)，這樣我們就可以得到一個理想的松耦合微服務(wù)體系。
2. 每個微服務(wù)一個數(shù)據(jù)庫
微服務(wù)模塊結(jié)構(gòu)設(shè)計好了，下面一個重要問題就是怎么處理數(shù)據(jù)庫，各個微服務(wù)是否共享數(shù)據(jù)庫呢？
如果共享，將導(dǎo)致微服務(wù)之間緊耦合，違背了微服務(wù)的松耦合原則。數(shù)據(jù)庫中一個小小的變動就需要各個團(tuán)隊同步修改。
如果每個微服務(wù)都有自己的數(shù)據(jù)庫，那么微服務(wù)之間的數(shù)據(jù)交換將非常麻煩，就像打開了潘多拉魔盒，跑出一堆問題，例如在多個服務(wù)中管理事務(wù)。
所以，很多人主張共享數(shù)據(jù)庫。
但是，微服務(wù)是持續(xù)的、長期的軟件開發(fā)，每個微服務(wù)應(yīng)該有其自己的數(shù)據(jù)庫。
3. 微前端
很多后端開發(fā)者輕視前端，認(rèn)為太簡單。
大多數(shù)架構(gòu)師也是后端出來的，在架構(gòu)設(shè)計中對前端不夠重視。
導(dǎo)致現(xiàn)狀就是，后端模塊化做的很好，而前端還是一整坨。
前端單體結(jié)構(gòu)和后端單體有一樣的問題，所以前端也需要進(jìn)行現(xiàn)代化的改造。
現(xiàn)在的 web 技術(shù)簡單、強(qiáng)大，例如 web 組件、Angular/React。
4. 持續(xù)交付
每個微服務(wù)可以獨立部署，是微服務(wù)架構(gòu)的核心優(yōu)勢之一。
比如你的系統(tǒng)包含 100 個微服務(wù)，現(xiàn)在有一個需要更新，那么你可以只需要發(fā)布這一個，而另外 99 個不需要動。
這就需要 CI/CD 和 DevOps，如果沒有這套自動化流程的話，就像拉著手剎開法拉利。
5. 可觀察性
微服務(wù)架構(gòu)簡化了開發(fā)，但復(fù)雜了運維。
單體結(jié)構(gòu)是非常便于監(jiān)控的，但在微服務(wù)架構(gòu)中，服務(wù)很多，而且通常是跑在容器中，對整個系統(tǒng)的監(jiān)控就變得非常復(fù)雜。
需要把所有容器、機(jī)器中的日志聚合到一起。
幸運的是已經(jīng)有成熟的解決方案，例如，使用 ELK/Splunk 處理日志，使用 Prometheus/App Dynamics 處理監(jiān)控。
還有一個比較重要的方面：調(diào)用跟蹤。
微服務(wù)間會產(chǎn)生級聯(lián)調(diào)用，為了分析系統(tǒng)延遲，就需要測量每個服務(wù)的延遲，Zipkin/Jaeger 提供了這個能力。
6. 統(tǒng)一技術(shù)棧
微服務(wù)體系中，不同服務(wù)有不同的特性，例如有的服務(wù)是 CPU 密集型操作，使用 C++/Rust 比較合適；有的服務(wù)是做機(jī)器學(xué)習(xí)的，使用 Python 比較合適。
所以，可以使用不同的技術(shù)處理相應(yīng)的需求，但是，一定要注意合理性，不要毫無根據(jù)的混合使用不同的技術(shù)。
想象一下，在一套系統(tǒng)中，有的微服務(wù)使用 Spring Boot + Kotlin+ React + MySQL，有的使用 JakartaEE + Java + Angular + PostgreSQL，有的使用 Scala + Play Framework + VueJS + Oracle。
這會不會讓人很崩潰，太難維護(hù)了。
7. 異步通信
服務(wù)間的通信問題是微服務(wù)架構(gòu)的重要挑戰(zhàn)，比是否共享數(shù)據(jù)庫那個問題還麻煩。
為了實現(xiàn)業(yè)務(wù)需求，需要多個微服務(wù)的協(xié)同工作，服務(wù)間需要進(jìn)行數(shù)據(jù)交換，一個服務(wù)需要觸發(fā)其他服務(wù)。
最簡單的就是通過 REST 接口直接調(diào)用，但這種同步調(diào)用方式問題比較大。
例如 A -> B -> C -> D，這種多級調(diào)用主要的3個問題：
- 增加了系統(tǒng)延遲。
- 每個服務(wù)可能會故障，這就產(chǎn)生了級聯(lián)性的錯誤。
- 服務(wù)間緊耦合。
最好是使用異步通信的方式，例如通過消息隊列（如 kafka）、異步的 REST（ATOM）、CQRS。
8. 微服務(wù)優(yōu)先
很多人認(rèn)為新項目應(yīng)該使用單體結(jié)構(gòu)，這樣起步快，比微服務(wù)簡單，當(dāng)發(fā)展大了之后再改造為微服務(wù)。
然而，這個改造是非常困難的，因為單體中模塊的耦合度太高了。
而且產(chǎn)品成熟后，對在線可用性要求很高，那個時候再改造的話，一定會中斷產(chǎn)品運行。
9. 基礎(chǔ)設(shè)施優(yōu)于類庫
Netflix 早期開發(fā)微服務(wù)時，主要使用 java 來開發(fā)，Netflix 開發(fā)出了很多優(yōu)秀的庫，如 Hystrix, Zuul，很多公司都使用他們。
后來，包括 Netflix 在內(nèi)的很多公司都發(fā)現(xiàn) java 其實并不擅長微服務(wù)開發(fā)，例如 java 體積過于龐大。
Netflix 轉(zhuǎn)向了 Polyglot，并停止了之前那些庫的維護(hù)，這就讓很多公司被動了。
所以，不要過度依賴特定語言的類庫，可以使用更底層的基礎(chǔ)框架，例如 Service Meshes。
10. 組織考慮
50 年前，Melvin Conway 發(fā)現(xiàn)公司的軟件架構(gòu)受限于其組織結(jié)構(gòu)。
其實在現(xiàn)在，這個觀點依然正確。
如果一個組織想使用微服務(wù)架構(gòu)，那么就應(yīng)該調(diào)整好團(tuán)隊的大小。
兩個披薩餅原則：如果兩個披薩不足以喂飽一個項目團(tuán)隊，那么這個團(tuán)隊可能就顯得太大了。
而且，團(tuán)隊成員應(yīng)該是多元化的，有前端、后端、測試、運維。
只有高層領(lǐng)導(dǎo)者轉(zhuǎn)變思維方式，微服務(wù)架構(gòu)才有可能發(fā)揮作用。
分享名稱：微服務(wù)的10個優(yōu)秀實踐，入門必看！
瀏覽路徑：http://www.5511xx.com/article/cogsdog.html
