微服務(wù)架構(gòu)，是當(dāng)前比較主流的架構(gòu)盔憨，最近剛好也了解了一些微服務(wù)架構(gòu)的內(nèi)容，所以也接著這個(gè)機(jī)會(huì)，整理一下對(duì)微服務(wù)架構(gòu)的了解亚茬。
微服務(wù)的定義
微服務(wù)是一種架構(gòu)風(fēng)格，一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成浓恳。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署刹缝，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)颈将。在所有情況下梢夯，每個(gè)任務(wù)代表著一個(gè)小的業(yè)務(wù)能力。
微服務(wù)架構(gòu)的優(yōu)勢(shì)
每個(gè)服務(wù)都比較簡(jiǎn)單晴圾，只關(guān)注于一個(gè)業(yè)務(wù)功能颂砸。
微服務(wù)架構(gòu)方式是松耦合的，可以提供更高的靈活性疑务。
微服務(wù)可通過(guò)最佳及最合適的不同的編程語(yǔ)言與工具進(jìn)行開(kāi)發(fā)沾凄，能夠做到有的放矢地解決針對(duì)性問(wèn)題。
每個(gè)微服務(wù)可由不同團(tuán)隊(duì)獨(dú)立開(kāi)發(fā)知允，互不影響撒蟀，加快推出市場(chǎng)的速度。
微服務(wù)架構(gòu)是持續(xù)交付(CD)的巨大推動(dòng)力温鸽，允許在頻繁發(fā)布不同服務(wù)的同時(shí)保持系統(tǒng)其他部分的可用性和穩(wěn)定性保屯。
微服務(wù)架構(gòu)的缺點(diǎn)
- 運(yùn)維開(kāi)銷及成本增加：
整體應(yīng)用可能只需部署至一小片應(yīng)用服務(wù)區(qū)集群，而微服務(wù)架構(gòu)可能變成需要構(gòu)建/測(cè)試/部署/運(yùn)行數(shù)十個(gè)獨(dú)立的服務(wù)涤垫，并可能需要支持多種語(yǔ)言和環(huán)境姑尺。這導(dǎo)致一個(gè)整體式系統(tǒng)如果由20個(gè)微服務(wù)組成，可能需要40~60個(gè)進(jìn)程蝠猬。
- 必須有堅(jiān)實(shí)的DevOps開(kāi)發(fā)運(yùn)維一體化技能：
開(kāi)發(fā)人員需要熟知運(yùn)維與投產(chǎn)環(huán)境切蟋，開(kāi)發(fā)人員也需要掌握必要的數(shù)據(jù)存儲(chǔ)技術(shù)如NoSQL，具有較強(qiáng)DevOps技能的人員比較稀缺榆芦，會(huì)帶來(lái)招聘人才方面的挑戰(zhàn)柄粹。
- 隱式接口及接口匹配問(wèn)題：
把系統(tǒng)分為多個(gè)協(xié)作組件后會(huì)產(chǎn)生新的接口喘鸟，這意味著簡(jiǎn)單的交叉變化可能需要改變?cè)S多組件，并需協(xié)調(diào)一起發(fā)布驻右。在實(shí)際環(huán)境中什黑，一個(gè)新品發(fā)布可能被迫同時(shí)發(fā)布大量服務(wù)，由于集成點(diǎn)的大量增加堪夭，微服務(wù)架構(gòu)會(huì)有更高的發(fā)布風(fēng)險(xiǎn)愕把。
- 代碼重復(fù)：
某些底層功能需要被多個(gè)服務(wù)所用，為了避免將“同步耦合引入到系統(tǒng)中”森爽，有時(shí)需要向不同服務(wù)添加一些代碼恨豁，這就會(huì)導(dǎo)致代碼重復(fù)。
- 分布式系統(tǒng)的復(fù)雜性：
作為一種分布式系統(tǒng)拗秘，微服務(wù)引入了復(fù)雜性和其他若干問(wèn)題圣絮，例如網(wǎng)絡(luò)延遲、容錯(cuò)性雕旨、消息序列化扮匠、不可靠的網(wǎng)絡(luò)、異步機(jī)制凡涩、版本化棒搜、差異化的工作負(fù)載等，開(kāi)發(fā)人員需要考慮以上的分布式系統(tǒng)問(wèn)題活箕。
- 異步機(jī)制：
微服務(wù)往往使用異步編程力麸、消息與并行機(jī)制，如果應(yīng)用存在跨微服務(wù)的事務(wù)性處理育韩，其實(shí)現(xiàn)機(jī)制會(huì)變得復(fù)雜化克蚂。
- 可測(cè)性的挑戰(zhàn)：
在動(dòng)態(tài)環(huán)境下服務(wù)間的交互會(huì)產(chǎn)生非常微妙的行為，難以可視化及全面測(cè)試筋讨。經(jīng)典微服務(wù)往往不太重視測(cè)試埃叭，更多的是通過(guò)監(jiān)控發(fā)現(xiàn)生產(chǎn)環(huán)境的異常，進(jìn)而快速回滾或采取其他必要的行動(dòng)悉罕。但對(duì)于特別在意風(fēng)險(xiǎn)規(guī)避監(jiān)管或投產(chǎn)環(huán)境錯(cuò)誤會(huì)產(chǎn)生顯著影響的場(chǎng)景下需要特別注意赤屋。
微服務(wù)架構(gòu)的取舍
- 在合適的項(xiàng)目，合適的團(tuán)隊(duì)壁袄，采用微服務(wù)架構(gòu)收益會(huì)大于成本类早。
- 微服務(wù)架構(gòu)有很多吸引人的地方，但在擁抱微服務(wù)之前嗜逻，也需要認(rèn)清它所帶來(lái)的挑戰(zhàn)涩僻。
- 需要避免為了“微服務(wù)”而“微服務(wù)”。
- 微服務(wù)架構(gòu)引入策略 – 對(duì)傳統(tǒng)企業(yè)而言，開(kāi)始時(shí)可以考慮引入部分合適的微服務(wù)架構(gòu)原則對(duì)已有系統(tǒng)進(jìn)行改造或新建微服務(wù)應(yīng)用逆日，逐步探索及積累微服務(wù)架構(gòu)經(jīng)驗(yàn)恼琼，而非全盤實(shí)施微服務(wù)架構(gòu)。
總結(jié)
最后總結(jié)一下屏富，其實(shí)微服務(wù)就是將原本非常臃腫的單體應(yīng)用拆分成若干個(gè)細(xì)粒度的小型服務(wù)，獨(dú)立進(jìn)行部署（現(xiàn)在的流行得益于docker容器技術(shù)的飛速發(fā)展）蛙卤，單獨(dú)開(kāi)發(fā)狠半、測(cè)試、運(yùn)維等颤难。
需要特別指出的一點(diǎn)神年，微服務(wù)并不是說(shuō)拆分得越細(xì)越好，而是要貼合業(yè)務(wù)行嗤，考慮整個(gè)系統(tǒng)的質(zhì)量屬性需求已日，根據(jù)實(shí)際情況進(jìn)行橫向拆分和縱向拆分。因?yàn)椴鸱值锰?xì)栅屏，那服務(wù)間的交互通訊以及運(yùn)維工作成本將大大提高飘千，拆分得太粗，又達(dá)不到微服務(wù)的效果栈雳。綜合以上的情況护奈，一般情況下首先是針對(duì)公共模塊的內(nèi)容進(jìn)行收集整理，打包成通用的服務(wù)哥纫，即橫向拆分霉旗；另外還需要考慮不同業(yè)務(wù)之間的耦合度，將相對(duì)獨(dú)立的“服務(wù)集”拆分到不同的服務(wù)中蛀骇，這就是我所理解的縱向拆分厌秒。所以現(xiàn)場(chǎng)場(chǎng)景下都是需要橫向拆分與縱向拆分相結(jié)合使用，才能讓微服務(wù)達(dá)到最好的效果擅憔。
