中小銀行做微服務(wù)容器化的必要性分析

1、 中小銀行做微服務(wù)容器化的必要性分析 中小銀行做微服務(wù)有必要一定要容器化嗎？現(xiàn)在中小銀行都在往微服務(wù)化這個(gè)方向去更新迭代自己的業(yè)務(wù)及技術(shù)架構(gòu)，企業(yè)做微服務(wù)有必要一定要容器化嗎？“很有必要”“初期就應(yīng)開(kāi)始容器化”dean25 民生銀行 軟件架構(gòu)設(shè)計(jì)師：從我們行實(shí)踐的結(jié)果看，是有必要的。沒(méi)有容器技術(shù)，微服務(wù)落地是非常困難的，僅僅是資源管理就會(huì)及其復(fù)雜，更別提調(diào)度和編排了。當(dāng)然，建設(shè)容器技術(shù)也是一個(gè)龐大的工程，不僅需要K8S+Docker，還需要匹配的自動(dòng)化發(fā)布系統(tǒng)、監(jiān)控系統(tǒng)、日志系統(tǒng)、運(yùn)維管理系統(tǒng)等。jason2006xu 昆侖銀行技術(shù)經(jīng)理：企業(yè)做微服務(wù)很有必要容器化。1、企業(yè)短期內(nèi)某些原因企業(yè)不

2、會(huì)實(shí)施Devops，但是為了提高開(kāi)發(fā)、測(cè)試以及運(yùn)維之間的效率中長(zhǎng)期必須實(shí)施devops。2、DevOps 主要用于開(kāi)發(fā)、測(cè)試以及運(yùn)維之間的協(xié)作管理，并且通過(guò)自動(dòng)化流程，更加快捷、頻繁、易重復(fù)且可靠的構(gòu)建軟件、測(cè)試及發(fā)布部署。3、在容器沒(méi)有出現(xiàn)之前也有 DevOps，并且發(fā)展了這么多年，企業(yè)常用的做法是通過(guò)自動(dòng)化腳本去實(shí)現(xiàn)配置引擎，例如：Puppet、Chef、Ansible 等工具。4、基于以上工具來(lái)實(shí)踐 DevOps，為什么沒(méi)有使得 DevOps 發(fā)展起來(lái)，而且在企業(yè)中落地艱難。除了腳本缺陷外主要體現(xiàn)在：人員強(qiáng)依賴；不具備收斂；非標(biāo)準(zhǔn)；不具備回退等。5、為什么說(shuō)容器技術(shù)恰恰能克服這些阻力呢？

3、第一，開(kāi)發(fā)使用簡(jiǎn)單，因?yàn)樵陂_(kāi)發(fā)的時(shí)候不需要關(guān)注這個(gè)機(jī)器還有運(yùn)行環(huán)境是什么，而能更加清晰的規(guī)劃開(kāi)發(fā)和運(yùn)維的界面。第二、抽象層次足夠高，解耦徹底，而且容器是行業(yè)通用的標(biāo)準(zhǔn)，DevOps 發(fā)展那么多年，為什么說(shuō)它沒(méi)有流行起來(lái)，比如說(shuō)剛才提到實(shí)現(xiàn) DevOps 平臺(tái)多種技術(shù)多種工具，這些工具的標(biāo)準(zhǔn)搬到其他的公司它未必適用，不同公司的文化也不一樣。容器標(biāo)準(zhǔn)的生命力特別強(qiáng)，容器可以讓 DevOps 普及發(fā)展以及流行，并且走出陰霾，證明 DevOps 的先進(jìn)性，也確實(shí)是可以落地的。塵世隨緣 技術(shù)總監(jiān)：容器和微服務(wù)是緊密集合在一起的，因?yàn)槲⒎?wù)會(huì)將單體應(yīng)用拆分成很多小的應(yīng)用，因而運(yùn)維和持續(xù)集成會(huì)工作量變大，而

4、容器技術(shù)能很好的解決這個(gè)問(wèn)題 ，使得服務(wù)可以切割得更小，成為支撐微服務(wù)很好的平臺(tái)。但是中小銀行在微服務(wù)起步階段，從技術(shù)架構(gòu)角度以及運(yùn)維角度都是一個(gè)全新的調(diào)整，所以建議在初期就開(kāi)始容器化，也算是試驗(yàn)階段。等后續(xù)團(tuán)隊(duì)技術(shù)沉淀后可大面積實(shí)施?！皼](méi)必要”“不宜過(guò)早過(guò)快的推進(jìn)容器化”yeefone 某大型保險(xiǎn)公司技術(shù)經(jīng)理：不一定?？梢試L試在部分業(yè)務(wù)上嘗試容器化，積累經(jīng)驗(yàn)，具體要看使用方的技術(shù)積累和團(tuán)隊(duì)能力，不宜過(guò)早過(guò)快的推進(jìn)容器化。楊文云 數(shù)據(jù)庫(kù)管理員：一般微服務(wù)和容器化都是一起做的，因?yàn)槲⒎?wù)本身數(shù)量大又復(fù)雜，容器和容器編排可以解決很多流量管理、監(jiān)控、資源管理等問(wèn)題，但根據(jù)各個(gè)微服務(wù)特性來(lái)決定，并不是

5、都有這個(gè)必要。個(gè)人總結(jié)的原因如下：1）容器化的主要目的是方便管理，但是容器化本身是會(huì)帶來(lái)性能的降低，一般不會(huì)存在一個(gè)主機(jī)上跑一個(gè)容器的情況。2）對(duì)于一些數(shù)據(jù)流量較大的服務(wù)，對(duì)性能要求較高的服務(wù)并不適合在容器內(nèi)去運(yùn)行。3）對(duì)整個(gè)容器化的掌握和理解需要一個(gè)團(tuán)隊(duì)，要不然技術(shù)債會(huì)背太多，沒(méi)有一個(gè)穩(wěn)定的團(tuán)隊(duì)做技術(shù)支持，不提倡全面的微服務(wù)有必要一定要容器化 ，如果沒(méi)有團(tuán)隊(duì)維護(hù)，后期出的問(wèn)題會(huì)更多。狄俄尼索斯 軟件架構(gòu)設(shè)計(jì)師 ：這兩者沒(méi)有耦合關(guān)系，是解耦的。微服務(wù)改造涉及的是業(yè)務(wù)開(kāi)發(fā)人員與架構(gòu)師；容器屬于基礎(chǔ)設(shè)施，運(yùn)維團(tuán)隊(duì)關(guān)注的。理想情況開(kāi)發(fā)人員不關(guān)注微服務(wù)是運(yùn)行在容器內(nèi)還是在虛擬機(jī)內(nèi)的。“不一定，但比較切

6、合”“容器是實(shí)踐微服務(wù)理念最好的承載”liufengyi 某互聯(lián)網(wǎng)銀行軟件架構(gòu)設(shè)計(jì)師：微服務(wù)與容器的關(guān)系是比較密切的，微服務(wù)運(yùn)行實(shí)體其實(shí)是進(jìn)程-服務(wù)，恰好與容器的單進(jìn)程模型吻合，再加上容器能保證環(huán)境的一致性，加速部署效率，能有效的減輕運(yùn)維成本，因此容器化是微服務(wù)的一個(gè)比較好的實(shí)踐。lyc19820 軟件開(kāi)發(fā)工程師：應(yīng)用做了微服務(wù)以后， 能夠?qū)崿F(xiàn)快速開(kāi)發(fā)迭代，但隨之帶來(lái)的問(wèn)題是測(cè)試和運(yùn)維部署的成本的提升。容器化的環(huán)境能幫助我們進(jìn)行這樣的解決方案，目前看來(lái)他是最成熟和可靠的方式，當(dāng)然也可能存在其他的方式，但是這個(gè)是被BATJ等各大公司采用且成功落地的方案。簡(jiǎn)單說(shuō)明一下：第一，應(yīng)用做了微服務(wù)拆分后，

7、需要進(jìn)行多個(gè)服務(wù)以及多個(gè)版本的的打包，測(cè)試，上線的量級(jí)信息大量增加，自動(dòng)化部署操作需求明顯增加第二，如果需要服務(wù)器的擴(kuò)容，需要進(jìn)行環(huán)境的初始化，與原先的環(huán)境一致。部署工作繁重。Docker容器可以完美的解決這個(gè)問(wèn)題。當(dāng)然容器技術(shù)不是萬(wàn)能的，但是它是最合適做微服務(wù)的一個(gè)技術(shù)！nameless 某云計(jì)算廠商 技術(shù)總監(jiān)：不一定，容器只是工具，從最佳實(shí)踐來(lái)說(shuō)容器和微服務(wù)比較切合。技術(shù)選型，工具選擇，一般從適合自己的角度出發(fā)，多個(gè)維度進(jìn)行比較。有些技術(shù)比較先進(jìn)，但不一定適合自己，選擇適合自己的最重要。1983michael1983 某證券技術(shù)經(jīng)理：那倒不盡然，只不過(guò)容器是微服務(wù)實(shí)現(xiàn)的最好工具和途徑而已。

8、尹學(xué)峰 售前技術(shù)支持：首先，需要明確的是微服務(wù)化和容器化是應(yīng)用架構(gòu)演進(jìn)的二個(gè)方向，二者沒(méi)有必然關(guān)系，也就是說(shuō)，可以做一個(gè)不依賴容器技術(shù)的微服務(wù)，也可以制作一個(gè)單體的容器化應(yīng)用。但是，更需要強(qiáng)調(diào)的是容器技術(shù)是實(shí)踐微服務(wù)理念的最好的承載。如果想把微服務(wù)理念的價(jià)值充分發(fā)揮出來(lái)，那么，就必須做容器化。打個(gè)比方：容器鏡像(image)就好比程序領(lǐng)域的類(class)而運(yùn)行狀態(tài)下的容器(container)就好比一個(gè)一個(gè)的實(shí)例(instance)不同的實(shí)例組合到一起，形成一個(gè)有機(jī)的整體，對(duì)外提供服務(wù)不知您是否理解我想表達(dá)的意思。“前提是微服務(wù)的規(guī)模有多大”、“是否全部、某類應(yīng)用非微服務(wù)化不可”gavin_

9、zhang 某股份制銀行 系統(tǒng)架構(gòu)師：前提是微服務(wù)的規(guī)模有多大。中大規(guī)模的系統(tǒng)：從目前的技術(shù)趨勢(shì)和以往的實(shí)踐來(lái)看，微服務(wù)和容器化部署還是結(jié)合比較緊密的。微服務(wù)系統(tǒng)一旦上了規(guī)模，成千上萬(wàn)個(gè)服務(wù)實(shí)例的運(yùn)維是一個(gè)很大的挑戰(zhàn)。容器和容器編排正是解決多服務(wù)和多實(shí)例的部署，維護(hù)，流量控制等問(wèn)題的解決方案。而且是目前來(lái)說(shuō)最好的解決方案。小系統(tǒng)（小于50個(gè)服務(wù)實(shí)例）可以考慮用自動(dòng)化部署工具支持。2010good 大型零售巨頭 系統(tǒng)工程師 ：微服務(wù)和容器化是非常緊密關(guān)系，不是必須關(guān)系，如果微服務(wù)規(guī)模較小，比如3-5個(gè)，且并發(fā)不大，或者短期內(nèi)并發(fā)變化不大，做與不做看心情。如果說(shuō)規(guī)模很大，比如一個(gè)項(xiàng)目有50個(gè)微服務(wù)

10、，平均每個(gè)微服務(wù)至少部署4個(gè)，這就是200，且并發(fā)變化較大，這樣使用容器就能快速部署，自動(dòng)擴(kuò)容和縮容。開(kāi)發(fā)和測(cè)試來(lái)說(shuō)也能快速測(cè)試，迭代。其實(shí)我覺(jué)得還是根據(jù)公司業(yè)務(wù)的特點(diǎn)來(lái)選擇，當(dāng)然如果條件成熟，微服務(wù)和容器并進(jìn)比較好，當(dāng)然也要看應(yīng)用類型，有些傳統(tǒng)的應(yīng)用也不太適合。（比如需要key的，不能宕機(jī)，自動(dòng)啟動(dòng)一個(gè)的）我愛(ài)大鍋飯銀行 系統(tǒng)運(yùn)維工程師：個(gè)人淺見(jiàn)，供參考：這個(gè)問(wèn)題我覺(jué)得要分2步來(lái)看。第一，要不要搞微服務(wù)拆分；第二點(diǎn)才是以何種技術(shù)實(shí)現(xiàn)微服務(wù)。微服務(wù)化是一種設(shè)計(jì)理念和架構(gòu)，容器是一種微服務(wù)實(shí)現(xiàn)技術(shù)。微服務(wù)化出現(xiàn)的背景有兩點(diǎn)：一是大型應(yīng)用遇到性能問(wèn)題（并發(fā)處理能力不足、數(shù)據(jù)庫(kù)成為集中的性能瓶頸），二是大型團(tuán)隊(duì)的合作問(wèn)題（一個(gè)大型團(tuán)隊(duì)一起開(kāi)發(fā)一個(gè)工程，效率低下），我個(gè)人認(rèn)為團(tuán)隊(duì)協(xié)作的問(wèn)題是微服務(wù)化的主要原因。所以回到您的問(wèn)題本身，是否貴行的全部、某類應(yīng)用真的已經(jīng)要到了非微服務(wù)化不可的地步，如果是，那么首先要考慮的是對(duì)原有的應(yīng)用要做何種拆分，拆分后的微服務(wù)規(guī)模多大，拆分出的微服務(wù)對(duì)現(xiàn)有的發(fā)布、運(yùn)維團(tuán)隊(duì)帶來(lái)多大的沖擊。如果說(shuō)原來(lái)的應(yīng)用拆分完之后也就變?yōu)?0個(gè)以內(nèi)的微服務(wù)，那么借助一些自動(dòng)化運(yùn)維工具也可以搞的定，畢竟使用容器也是有額外的成本的（應(yīng)用去狀態(tài)化、應(yīng)用日志改造、排錯(cuò)習(xí)慣、容器調(diào)度機(jī)制設(shè)計(jì)）。但是如果一旦拆分后的微服務(wù)規(guī)模達(dá)到一定量級(jí)（現(xiàn)有開(kāi)發(fā)、測(cè)試、運(yùn)維團(tuán)隊(duì)安裝原來(lái)的工作