原創(chuàng)文章,歡迎轉(zhuǎn)載。轉(zhuǎn)載請注明:轉(zhuǎn)載自IT人故事會,謝謝!
原文鏈接地址:『高級篇』docker容器來說微服務(wù)優(yōu)勢和不足(四)安鄉(xiāng)ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景,ssl證書未來市場廣闊!成為創(chuàng)新互聯(lián)公司的ssl證書銷售渠道,可以享受市場價格4-6折優(yōu)惠!如果有意向歡迎電話聯(lián)系或者加微信:028-86922220(備注:SSL證書合作)期待與您的合作!
來看看微服務(wù)有哪些優(yōu)勢和不足。
獨立性
從構(gòu)建部署,擴容收容,容錯,數(shù)據(jù)庫都是單獨管理的。每個服務(wù)之間都是單獨管理。一個微服務(wù)出現(xiàn)問題,只會影響他自己。并不會影響整個服務(wù)。每個都獨立的數(shù)據(jù)庫。
敏捷性
對于使用者來說微服務(wù)暴露的接口相對簡單,因為他們的功能都很單一,清晰的api,同時也可以很快的應(yīng)對變化,針對新需求很快的找到需要修改的微服務(wù),去修改就可以。
技術(shù)棧靈活
api接口不變就可以了,服務(wù)重構(gòu)。
每個團隊只負責自己的微服務(wù),做些架構(gòu)調(diào)整,架構(gòu)變化,幾個人開個小會就可以了。
沒有最好的架構(gòu),只有最適合的。
額外的工作
服務(wù)的拆分,其實服務(wù)的拆分是一門非常深的學(xué)問。
數(shù)據(jù)的一致性
單體一個數(shù)據(jù)庫,很容易做到一致性,微服務(wù)都有自己的服務(wù),雖然我們在微服務(wù)盡量減少連表操作,盡量在同一個微服務(wù),也難免出現(xiàn)這樣或者那樣的關(guān)聯(lián)關(guān)系。
api的改變,單體架構(gòu)中,想改一個接口可以將調(diào)用這個接口的地方順便改掉,但是在微服務(wù)中,你想改的地方不是你負責,推動其他人其他組來修改。如果其他人或者其他組比較多的溝通成本就很明白了。
軟件開發(fā) VS DDD
一般軟件設(shè)計或者說軟件開發(fā)分兩種:瀑布式,敏捷式。
前者一般是項目經(jīng)理經(jīng)過大量的業(yè)務(wù)分析后,會基于現(xiàn)有需求整理出一個基本模型,再將結(jié)果傳遞給開發(fā)人員,這就是開發(fā)人員的需求文檔,他們只需要照此開發(fā)便是。這種模式下,是很難頻繁的從用戶那里得到反饋,因此在前期分析時就已經(jīng)默認了這個業(yè)務(wù)模型是正確的,那么結(jié)果可想而之,數(shù)月甚至數(shù)年后交付的時候,必然和客戶的預(yù)期差距較大。
后者在此基礎(chǔ)上進行了改進,它也需要大量的分析,范圍會設(shè)計到更精細的業(yè)務(wù)模塊,它是小步迭代,周期×××付,那么獲取客戶的反饋也就比較頻繁和及時??擅艚菀膊荒軌?qū)I(yè)務(wù)中的方方面面都考慮到,并且敏捷是擁抱變化的,大量的需求或者業(yè)務(wù)模型變更必將帶來不小的維護成本,同時,對人(Developer)的要求也必然會更高。
PS:微服務(wù)的要求是分析的足夠小的顆粒,項目分析的透徹。