9月6日，由深圳金融信息服務協(xié)會主辦，我公司（深圳睿云智合科技有限公司）與Rancher Labs聯(lián)合協(xié)辦的，深圳金融IT界容器技術專題研討會隆重召開并勝利閉幕！

 

會議匯聚了國內(nèi)外知名的云計算技術大咖，以及招商銀行、平安科技、富德生命人壽、廣發(fā)證券等國內(nèi)金融科技引領企業(yè)的容器技術實踐團隊的經(jīng)驗分享，為150多人的在場嘉賓奉上了一場堪稱金融行業(yè)與最前沿容器技術的巔峰碰撞！

 

除了深圳本地的金融行業(yè)技術人員，更有來自北京、上海、東北的多家金融機構信息技術團隊積極參與，大家紛紛表示會議干貨多多，收獲頗豐。

 

以下就是小編為大家整理的嘉賓分享內(nèi)容系列速遞，按照演講順序，今天繼續(xù)為大家推出的是來自廣發(fā)證券首席架構師兼信息技術部副總經(jīng)理?– 梁啟鴻?的分享：《容器化與組織結構》

 

 

首先，梁啟鴻先生以新常態(tài)與去庫存展開分享，并且結合金融IT以及現(xiàn)在互聯(lián)網(wǎng)發(fā)展態(tài)勢，進行了探討：

對于現(xiàn)在傳統(tǒng)企業(yè)的IT架構而言，代碼庫存繁多、雜亂?、變更快，從而導致運維風險大、成本高，從而無法很好的管理這些代碼庫存。很多企業(yè)就想抓住這樣技術變革的機會進行彎道超車，就拿如火如荼的金融行業(yè)來說，正在緊鑼密鼓的部署著一套套屬于自己的架構體系。

除此之外，梁啟鴻先生還介紹了互聯(lián)網(wǎng)區(qū)塊鏈中的分布式、去中心化、去庫存的架構。對于這樣的架構我們可能需要用到微服務（微服務架構）。一旦采用微服務，由于生產(chǎn)工具影響生產(chǎn)者關系，容器工具鏈便成了一個重量級的殺手武器容器！

 

容器化

容器化?– 可能是過去五年來軟件業(yè)最重要的“運動”。容器技術的出現(xiàn)其實是一種潮流，一種趨勢，但為什么又要稱之為運動呢?

他改變了我們的交付方式，改變了我們的軟件思維。等到容器工具出現(xiàn)的時候，DevOps才得到真正的發(fā)展。

一

理性認識容器化技術

 

• 技術問題解決的關鍵，沒有“銀子彈”，容器不是“黑科技”
• 容器技術，促進了更多新技術發(fā)展；
• 容器工具鏈，促進DevOps；
• 用容器工具鏈，更便于遵循Micro Service、Reactive、12-Factors 等架構風格、最佳實踐；

 

• 容器對你的代碼沒有入侵性– 不會讓系統(tǒng)更快或者更慢；對你的架構有入侵性– 一旦采用你就要走分布式架構。

二

容器出現(xiàn)前后的云計算

容器出現(xiàn)前大家認為云計算是運維人員使用的技術，接觸最多的就是虛擬機。用虛擬機的api與業(yè)務應用相結合。這個時期應用架構并沒有受到云計算的影響。而容器出現(xiàn)后，云計算技術向應用轉移，開發(fā)者成為它的直接用戶，編排好的容器里的東西運維不需要關注。要用好容器，需要了解好分布式的架構。還用以前的應用架構去搭建是不現(xiàn)實的。

 

 

 

組織結構

影響組織結構的技術、架構理念與技術運動如下：

? 云計算：IaaS/PaaS/SaaS

? 微服務：MicroServices、Containerization

? DevOps：APM、InfrastructureAsCode、ImmutableInfrastructure、ITAutomation…

 

一

單體架構組織以及微服務架構組織

 

所謂servlet、mvc這些都是一些傳統(tǒng)的方式。到2013我們開始用這種全棧同構的基礎架構同時走這種微服務方向，你比如像這種電商服務產(chǎn)品中心，購物車，適當性管理形成一些單一的微服務，這些微服務是可以共享這些應用的。

二

Gartner的“內(nèi)架構”與“外架構”

 

在Inner Architecture中singleresponsibility這種單一微服務，他的邊界是很清晰的，技術主要聚焦在業(yè)務，有時需要2、3個人的小團隊去負責。而outer Architecture，他的可用性、彈性、韌性就只需交給平臺去負責管理即可，它有著強大的監(jiān)控部署體系同時兼容著PaaS平臺即服務，這也是容器技術出現(xiàn)之后，PaaS變得更可用、更現(xiàn)實，還解決了一些PaaS中出現(xiàn)的繁瑣、碎片化的問題。

三

從Silo型到Matrix型到DevOps型

 

說到組織結構是從silo型到matrix型到devops型慢慢演變的一個過程。要想建立良好的組織結構，首先需要建立一個平臺團隊，每一個項目以產(chǎn)品經(jīng)理去驅(qū)動。保障交付的時間，不保障交付的功能。對于傳統(tǒng)的流程是從業(yè)務的需求，審批，再到硬件的采購，軟件的開發(fā)，再測試部署，最后客戶反饋，每一個環(huán)節(jié)可能是一個禮拜或者一個月，而現(xiàn)有的agile devops則是直接從業(yè)務到軟件開發(fā)部署，最后反饋，節(jié)省了很多時間。

四

原則建議

 

? 大系統(tǒng)小做（別想“一口吃個胖子”）

? 小團隊可以做大事情（從電商到交易終端到交易系統(tǒng)，都是幾個人開始）

? 全棧（Fullstack）型技術團隊讓架構更加靈活

? Conway ‘sLaw（康威定律），不要和它“抗爭”，遵循它

? Brooks’ Law-技術系統(tǒng)設計的理念，不應該建立在“加人就能增加團隊生產(chǎn)力”這種假設上

? 利用工具反過來促進持續(xù)試驗與學習的文化

五

圍繞OODA閉環(huán)的持續(xù)交付組織

 

boyd ?Loop是美國空軍在實戰(zhàn)中觀察總結的決策閉環(huán)。后來netflix利用亞馬遜云的ami實現(xiàn)10分鐘級別的更新部署。?代碼越多，bug越復雜，生產(chǎn)環(huán)境就越不穩(wěn)定，形成反脆弱組織的一個期望，我們需要怎么去做呢？就是同一個組織，同一個夢想，同一個kpi，讓開發(fā)與運維，同一套工具。

?

 

總結

在分享結束之際，梁啟鴻先生還總結了：所有金融系統(tǒng)都是一系列組裝系統(tǒng)，復雜系統(tǒng)是分開人和機器兩個部分的，那么把IT作為一個孵化器，啟動一個快速迭代，快速創(chuàng)新同時能夠支持像OODA閉環(huán)這樣的環(huán)境，將其應用實踐于業(yè)務生產(chǎn)中才是我們真正需要做的！