<th id="0poub"></th>
  1. <th id="0poub"><track id="0poub"><dl id="0poub"></dl></track></th><dd id="0poub"><track id="0poub"></track></dd>

    <dd id="0poub"></dd>
    <dd id="0poub"><pre id="0poub"></pre></dd><th id="0poub"></th>
    <th id="0poub"><track id="0poub"></track></th>
    <tbody id="0poub"><pre id="0poub"></pre></tbody>
    <em id="0poub"><acronym id="0poub"><kbd id="0poub"></kbd></acronym></em>
    logo

    地址:深圳南山區大沖國際中心21樓

    聯系我們 : contact@wise2c.com

    產品支持 : service@wise2c.com

    售前咨詢 : sales@wise2c.com

    電話: +86 (755) 33268246

    粵ICP備16049363號

    Author: admin

    深圳睿云智合科技有限公司 > Articles posted by admin
    • All
    • 技術漫談
    • 最佳實踐
    • 睿云新聞
    • 行業資訊

    微服務轉型與DevOps

    分享人:鄭云龍   睿云智合持續交付產品負責人,在敏捷和DevOps領域有豐富經驗的實踐,過去作為敏捷和DevOps技術教練向多家大型企業提供咨詢和培訓服務。   微服務轉型與DevOps 1   遺留的現狀 在開始微服務和DevOps主題之前,首先看看在過去我的咨詢工作中,對于大部分咨詢客戶而言,企業會邀請外部的顧問來對團隊進行改進,最主要的原因都是由于現有的研發體系和產品團隊,難以跟上市場的變化,希望通過外部顧問,通過一些手段來提高產品團隊的響應力。敏捷實踐亦或是DevOps實踐最終的目的都是為了能夠快速的交付高質量的軟件產品。 究其原因,為什么這類客戶會有如此大的需求去引入敏捷或者DevOps呢?遺留系統。 歷史遺留問題與新問題,新需求的持續混合發酵,導致系統的開發效率無法滿足業務的發展需求。所以經常會有如上圖這種對話。無論是新的需求,還是遺留的Bug都嚴重受制于遺留系統 如果從技術角度來看,對于遺留系統最主要的問題包括:高耦合性,底可測試行,代碼質量差,圈復雜度高,并且很難對系統進行優化。而這些東西我們都可以稱之為技術債。 而這些技術債務的積累最終導致我們的系統越來越難以維護。舉個例子,在之前對客戶團隊進行敏捷技術培訓時,嘗試在項目中使用TDD,最終的結果是在使用TDD的同時,我們進行了大量的重構,才能保證我們能夠順利的給某一個業務場景添加上相應的測試代碼。 而技術債不是一開始就有的東西,對于傳統單體架構而言,在項目初期系統通常也是易于開發,易于部署,易于測試的。 隨著時間和項目演進,系統的代碼量以及復雜度呈指數型增長,最終導致我們整個項目的交付周期越來越長,同時系統很難進行擴展,并且當擴展時所需要的成本也越來越高。 對于新加入團隊的成員,也需要花費大量的時間了解業務背景,熟悉應用程序的業務,配置本地開發環境等等。這些看似簡單的任務,往往需要花費大量的時間。 同時對于傳統單體架構隨著時間和項目的演進,嘗試引入新技術或者對現有技術框架進行改進的成本和風險也越來越高。 而對于傳統的SOA架構? 如果用直白一點的話來說,就是專注于使用ESB來集成企業內的各個單體應用。而往往導致的結果是兩個大的中心化,技術的中心化,以及流程的中心化。 由于EBS通?;谔囟ǖ募夹g棧,并且使用了中心化的標準個規范,使得業務難以根據業務場景去選擇合適的技術。 而ESB也往往嵌入了大量的業務流程,所以導致任何服務的修改都需要進過復雜的流程,修改系統的工作量不減反增,維護成本和產品成本也呈非線性增長。   2   什么是微服務架構 通常而言我們對于微服務并沒有一個準確的定義,但是我們可以認為,微服務就是我們去以正確的姿勢去實現SOA。 對于微服務通常具有以下特性:獨立進程,獨立部署,獨立技術以及獨立團隊。 對于每一個服務而言都是以開發一個小的獨立的應用系統,并且每個服務都是運行在自己的進程中;這些服務圍繞業務功能進行構建,并且能夠獨立的部署和發布;同時服務與服務之間可以使用不同的技術語言以及存儲技術;而對于每一個微服務都是由一個充分獨立自治的團隊進行端到端的管理,從開發,構建,部署,上線運維。并且這些服務之間通常采用一些輕量級的通訊接口包括像Rest API以及消息隊列 而對于每一個微服務而言我們都可以根據其不同的業務場景去選擇適合的技術,并且這些服務之間可以有不同的發布節奏 除了技術上的去中心化,在團隊組織結構上,每一個微服務團隊都應該具有和當前業務功能開發所需的全方位技術,及所謂的全功能團隊。這些團隊圍繞著各自的業務管理相關的服務。相比于傳統的通過組件的方式拆分團隊,微服務團隊可以端到端的完成特性交付,減少由于將特性分配給多個團隊而導致的溝通問題,系統集成問題,能夠更加快速的交付所需的特性,減少等待時間。 同時微服務架構能夠幫助我們快速的開辟新的渠道,助力企快速獲取市場機會。 剛才談了很多關于微服務本身的特性,以及能夠為我們帶來的好處。但是事無好壞,對于任何一家公司和組織,在轉向微服務之前都應該明白它為我們帶來的潛在的挑戰。   微服務化帶來的挑戰? 運維的挑戰?、質量保證體系、分布式系統的復雜度   首先我們來說關于質量的部分 對于任何傳統意義上的測試保障體系,我們通常會通過單元測試,API測試,系統集成測試,以及其他的非功能性測試,諸如性能測試,安全測試等來保證我們軟件交付的質量。在敏捷測試實踐中我們通常以測試金字塔的方式來評估我們現有系統的自動化測試水平以及合理性。 那在微服務中呢?剛才我們已經說過,微服務是一組獨立的去中心化得服務,服務和服務之間必然存在相應的依賴關系。   在這里我們仿照敏捷測試金字塔的方式將微服務的質量保證體系劃分為3層:服務內,服務間,以及服務集成。 相比與過去的軟件質量保證體系,我們增加了契約測試來保證服務和服務之間的依賴,確保各個服務是能夠獨立的進行演進升級的。對于契約測試目前包括像Thoughtworks開源的契約測試工具Pact以及Swagger這樣的工具都能夠幫助我們將契約測試添加到我們的質量保證體系中。 當然對于所有的自動化的質量保證過程,我們都應該將他們納入到CI流水線中,通過自動化的方式來保證我們每一次代碼變更都是能夠滿足質量要求的。 那對于運維體系而言呢?       運維體系面臨的挑戰 1,部署環境的多樣性,對于傳統團隊的Ops人員,他通常都是接觸一些固定的技術棧相關的運維和管理工作,但是在服務下,每一個服務都都可能采用不同的技術,數據庫,以及中間件。那對于Ops人員而言所需要面臨管理和運維的環境的復雜度和難度也隨著服務化得進程變得越來越困難 2,對于公司而言從開發,測試到部署上線,我們通常需要使用大量的服務器資源來保證我們各個環節的部署環境需求。舉例來講,在敏捷當中我們通常會有Dev環境,UAT環境,Prod環境去提供軟件交付過程中各個階段的部署需求。但是微服務之后我們可能有幾個,幾十個甚至幾百個不同的服務,而這些服務都需要相應的部署資源,同時如何保證各個階段的環境一致性問題 3,CI維護成本暴增,在過去我們通常會花費通常一個迭代的時間來搭建我們項目的CI基礎設施,但是現在隨著服務數量的增加我們管理和配置Jenkins的成本也越來越大 4,除此之外包括,日志,監控,彈性,高可用都是我們在微服務轉型過程需要面臨的挑戰。 如何解決 充分授權團隊 在微服務下我們希望每一個團隊都是能夠充分獨立和自治的。但是往往對于企業而言對于基礎設施環境的管控要求其實非常高,包括像網絡,安全等等。 所以往往對于一個團隊想要獲取一個服務器資源通常需要復雜的審批以及配置過程。 而通過引入像Rancher這樣的輕量級的容器化管理平臺,我們可以將底層基礎設施的管理問題交給專門的運維團隊來進行處理。這些基礎設施可以是物理機,IaaS,甚至是容器集群。并且將這些資源按照環境的形式分配給不同的團隊,充分授權團隊,管理自己的所有的開發,構建與部署環節。   基礎設施代碼   而對于持續集成流水線,以及持續交付流水線的管理和配置,Jenkins2.0通過Pipeline As Code的方式通過編寫DSL來幫助我們實現全面的基礎設施及代碼的要求。 在代碼庫當中及包含源代碼src,也包含我們的環境準備過程Dockerfile以及環境定義docker-compose.yml. rancher-compose.yml. 同時我們將我們的持續交付流水線也通過Jenkinsfile的形式保存在源代碼庫中,那么只要我們獲取了軟件倉庫的代碼,就能夠獲取支撐我們軟件交付各個階段的所有物品,包括源代碼以及運行時環境。并且對于任何代碼或者環境的變更都能夠通過持續交付流水線進行持續的驗證和反饋 同時Rancher也提供了內置的監控功能:包括主機以及容器。通過Catalog我們也能快速的搭建ELK的日志分析平臺以及其他的監控服務。 通過服務容器化,以及引入諸如Rancher這樣的容器管理平臺。我們可以使我們的研發團隊更加專注于軟件架構以及環境架構的設計,而將一些其他的運維和管理工作交給容器管理平臺來管理。能有效的減少我們在DevOps實踐當中的成本,包括人員能力以及自動化能力的要求。   同時對于微服務團隊而言,我們基于持續交付流水線能夠使軟件交付各個階段的人員能夠有效的協同工作,保證我們能夠又快又安全的交付軟件,每一次代碼變更都能夠產生一個可工作的軟件(當然前提是這些人都是屬于同一個團隊) 所以對于轉型微服務而言,我們需要明白持續交付以及DevOps文化是支撐我們微服務轉型的一個重要手段。 我們需要有獨立自治的全功能型團隊,通過引入虛擬化技術,容器化技技術,以及相應的管理平臺來減少我們部署和運維的復雜度。并且通過更加完善的質量保證體系來確保我們的服務能夠確實的去支撐我們的軟件交付質量。     總結   就像開篇說的一樣,“微服務可能是實現SOA的最正確的姿勢”,它實際上是我們軟件交付領域大量優秀實踐的一個集合。同時微服務是不銀彈,在引入微服務后我們同時需要面對更多復雜的問題。 通過引入容器化,以及容器化管理平臺能夠減少我們在轉型微服務過程中的大量成本;通過小步嘗試,積累經驗和能力,能夠幫助我們在微服務化轉型中走的更加順暢; 同時根據不同的業務模式選擇不同的微服務重構模式能夠幫組我們能夠在解決現有問題的同時來全面提升我們整個產品的響應力; 最后一張圖,簡單總結了一下微服務中關于實踐與設計模式的概覽,希望能夠對大家在服務化轉型中提供幫助; 最后在準備這次分享的過程中我準備了一些例子,包括Jenkins2的容器化,以及基于Jenkins2和Rancher實現端到端的持續交付過程: https://github.com/yunlzheng/rancher-jenkins2 https://github.com/yunlzheng/jpetstore-6 有興趣的同學可以進行參考,當中不完善的部分也希望能夠提供反饋,能夠進行相應的改進。...

    Read More

    深入理解Kubernetes網絡策略

    分享人:梁文智-睿云智合研發顧問   時間:2017-7-20   當我們逐漸向著微服務、云原生邁進的時候,傳統靜態的、相對簡單的網絡安全策略開始顯得吃力。?Kubernetes 的?Network Policy 特性正是來解決這個問題的。在剛剛出爐不久的1.7版本中,該特性也被扶正成為GA。讓我們來一起看看?Network Policy 是什么,能為我們做什么,以及是如何實現的。   CNI     Kubernetes 對網絡做了較好的抽象。它將對網絡的需求交給外部的組件完成,也就是?CNI driver。   Pod 的網絡必須滿足以下三個需求:   1 所有?Pod 之間無需?NAT 即可互通 2 主機和?Pod 之間無需?NAT 即可互通 3 Pod 自省的?IP 地址和之外部看到該?Pod 的地址一致   CNI 對網絡的實現做了詳細的定義。CNI 的實現可以被分成三種:   1 3 層路由實現 2 Overlay 實現 3 2 層交換實現   現在比較常用的?CNI 實現有:Flannel、Calico、Weave。?Flannel 通過?VXLan Overlay 來實現跨主機?Pod 網絡,?Calico 則完全通過?3 層路由來實現了跨主機的容器網絡,Weave也是?Overlay 的實現。   什么是Network Policy     隨著業務邏輯的復雜化,微服務的流行,越來越多的云服務平臺需要大量模塊之間的網絡調用。   傳統的單一外部防火墻,或依照應用分層的防火墻的做法漸漸無法滿足需求。在一個大的集群里面,各模塊,業務邏輯層,或者各個職能團隊之間的網絡策略的需求越來越強。   Kubernetes 在?1.3 引入了?Network Policy 這個功能來解決這個問題。這些?Policy...

    Read More

    度量驅動的DevOps轉型

    分享人:鄭云龍 時間:2017-1-17   睿云智合持續交付產品負責人,在敏捷和DevOps領域有豐富經驗的實踐,過去作為敏捷和DevOps技術教練向多家大型企業提供咨詢和培訓服務。   虛擬化,容器化,云計算,自動化為DevOps運動提供了底層技術支持,新的工具鏈和技術棧的采用進一步降低了DevOps的技術門檻,越來越多的企業紛紛開始自己的DevOps轉型之路,然而…… ? DevOps以及企業DevOps轉型的現狀 ? 為什么我們需要在DevOps轉型中強調度量 ? 如何實現度量驅動的DevOps轉型 ? DevOps轉型中的其它實踐     Wiki上講:DevOps(Development和Operations的組合詞)是一種重視“軟件開發人員(Dev)”和“IT運維技術人員(Ops)”之間溝通合作的文化、運動或慣例?(這個是目標)透過自動化“軟件交付”和“架構變更”的流程(這個是方法)來使得構建、測試、發布軟件能夠更加地快捷、頻繁和可靠(這是結果)。 所以對于企業來說的真正價值則在于通過團隊間協作關系的改善,?整個組織效率的提升的同時,可以有效降低伴隨頻繁變化而帶來的生產環境風險,從而提升企業應對市場變化響應力。   根據2016 DevOps調查報告顯示。成功實施DevOps組織可以更快的去適應整個市場環境的變化,同時能夠更快的做出調整。 擁有相比競爭對手擁有更加高的部署頻率,更快的故障恢復時間,更低的變更失敗率以及以及更短的需求交付周期。     然后當企業大量的采納并使用這些新的工具鏈之后,我們并沒有看到我們所交付的軟件真的如同DevOps的目標一樣,能夠真正的實現軟件快捷,頻繁并且可靠的交付。     DevOps不是盲目的使用新的工具鏈和技術棧,通過自動化部署流水線的方式,將低質量的代碼頻繁的部署到運行環境。 目前實施DevOps轉型的傳統企業,通過引入自動化確實能提升在軟件交付的某些環節中的效率,但是卻很難去提升軟件的交付質量,依然引入獨立的測試部門進行大量的系統測試來確保軟件的質量,同時企業也很難度量持續交付和DevOps實施的效果。 所以目前大部分企業基本上是把自動化當做DevOps在做,把自動化部署當做持續交付在做,而很少去考慮軟件交付流程的整體性優化。 自動化是實施DevOps的先決條件但是并不能真正的幫助企業跨越DevOps轉型的鴻溝的銀彈。     而對于DevOps的成功轉型而言,我們需要做的是持續的對我們的軟件交付過程進行優化,發現軟件交付過程各個環節中存在的瓶頸并持續改進。       You Can’t Fixed What You Can’t. 而數據和度量則是幫助企業去發現DevOps轉型過程中的瓶頸并且做出改進的關鍵基礎。     在開始時我們說從Wiki上看,DevOps會主要設計到3個部分:目標,方法和結果。 所以從度量的交付上看我們需要從兩個方面去度量我們的DevOps轉型。哪些度量指標是能夠支撐企業判定DevOps轉型結果。而哪些是能夠去評判軟件的交付過程,并且用于發現交付瓶頸的。     根據2016DevOps報告顯示,目前度量企業DevOps轉型是否成功的最終結果性關鍵指標包括: 吞吐量指標:部署頻率,變更交付周期。 穩定性指標:變更失敗率,問題平均恢復時長(mean time to recover)。 吞吐量即敏捷性,確保企業能夠適應市場的變化,并且快速做出反饋。穩定性,即高質量。     相比于傳統的IT服務流程績效指標ITIL而言,DevOps更加關注結果性指標,?即客戶價值。 就好比我們做軟件交付和外賣小哥其實很像,可以評價一個產品是否優秀更多的是看交付效率如何,質量如何,并且是不是能夠滿足我的預期的? 這兩種截然不同的度量方式本質就是OKR和KPI的區別: OKR基于目標和關鍵成果,促使我們思考,溝通,每個人都知道什么是最重要的;并且能讓團隊所有人共同的為某件事而努力。 所以對于基于OKR驅動的DevOps可以確保參與軟件交付過程中的所以角色圍繞具有通過的目標,并且為了這些共同目標去嘗試新的技術和方法。 而KPI理論則避免按照SMART標準制訂,有些事情值得去做,但在做出來一部分之前無法測量因此無法制訂目標。KPI 還有一個更嚴重的問題,那就是為了完成可測量的目標,有可能實際執行手段與該目標要達到的愿景正好相反。 KPI使得團隊使勁往前走,而OKR則確保團隊能夠往正確的方向走。而在軟件交付過程中,開發,測試,運維都有著不同的考核標準。所以KPI能夠團隊各個成員使勁的按照各自的目標走,而OKR則確保團隊能夠一起往正確的方向走。 DevOps需要的是整體性的優化,當你選擇自己企業內部的度量標準時,請問自己兩個問題: 為什么需要度量這個指標?從這個指標中我們能學到什么?         根據DevOps 2016報告高效的IT組織與中等和低效的IT組織之間在DevOps最終結果性關鍵指標存在則顯著的差異。 DevOps的最終結果性指標能夠幫助企業去衡量和評判DevOps轉型的結果。     當然除了結果性的指標去驗證DevOps轉型所起到的作用以外,我們還需要持續的度量其他的數據去幫助我們發現在軟件交付各個階段的問題。 包括從需求管理,源碼管理,構建過程,測試過程,部署過程,發布,配置管理,監控等各個方面,這里我們列舉了在各個過程當中可能需要的一些度量數據。 其中比較典型的包括通過對需求管理進行度量,我們可以知道從需求到需求部署上線的變更交付時間。 在CI過程中我們持續的去獲取相關的過程數據,如構建次數,構建頻率,構建時長,成功率,平均恢復時間等可以幫助團隊去判定研發團隊是否能夠做到小步提交,頻繁提交,并且當發現問題之后能夠快速的恢復。 除此之外,低質量的,高復雜度的代碼也會使得軟件交付效率無法得到有效提升,所以我們需要持續的獲取代碼質量相關的數據,持續改進代碼質量等等。     所以對于度量驅動的DevOps轉型而言,我們需要持續的去獲取在軟件交付各個階段所產生的數據,以及軟件部署上線之后的監控數據,用戶行為數據等,并且形成對團隊所有人可見的DevOps可視化看板。 而產品/需求管理人員,則可以根據DevOps結果性數據去評價在過去一段時間內DevOps實施所產生的效果,從過程性數據中去發現交付過程中的瓶頸,根據用數據以及線上監控數據去評價軟件產品是否如預期的一樣產生相應的價值,如果沒有,是否應該做出及時的調整。 除了通過自動化的方式去構建軟件交付的端到端流程提升軟件交付,并且持續的獲取軟件交付的各個階段所產生的數據以外。 我們還應該在軟件交付流程中去設置相應的門禁機制,去讓不滿足質量要求的構建快速失敗。     在實踐當中,根據軟件產品的體量的不同完整運行端到端自動化的過程可能會非常長。 所以對于研發團隊而言,持續部署流程所產生的反饋周期過長,不利于研發團隊快速發現和解決問題。 1 基本CI流水線頻繁執行,由代碼提交觸發,包含構建,單元測試,集成測試,代碼靜態掃描,部分自動化驗收測試等(端到端運行周期短)。 2 FOR TEAM:全量流水線每日定時多次觸發,包含構建,單元測試,集成測試,代碼掃描,全量的自動化驗收測試,部署,部署冒煙測試等等(端到端運行周期長)。 3 FOR QA:手動指定版本部署,手動觸發。 通過分層流水線,在滿足快速反饋的原則的同時,又能持續的對軟件進行集成和測試。     同時在流水線當中通過引入質量門去控制代碼質量,避免技術債務的積累。 當然對于歷史遺留系統而言,通常會存在大量的歷史債務,這時候我們可以將當前系統的代碼質量作為基線標準,同時針對新增代碼設置質量門控制,包括新增代碼的代碼風格,復雜度,測試覆蓋率等。     通過可視化流水線將將持續部署流水線的構建過程向整個團隊進行展示,讓所有人都知道當前的項目構建狀態以及進度,如果又構建失敗了,成員之間也可以相互提醒盡快修復流水線的失敗。     持續的獲取過程有效性數據和質量有效性數據為團隊提供可視化看板。     除了門禁機制以外,質量內建也是團隊成功實施DevOps的關鍵因素,通過在軟件交付的各個階段建立自動化的保障體系可以使團隊能夠盡早的發現和解決發現的缺陷。     對于度量驅動的DevOps轉型,通過自動化部署流水線有效提高軟件交付的效率,通過質量內建確保軟件交付的質量,通過對過程性數據的持續收集和分析發現交付過程中存在的瓶頸,通過對軟件產品和用戶的線上數據獲取反饋并且及時作出調整,通過結果性數據去評價團隊的成效。     最后對于企業DevOps轉型而言: Automation 自動化是實施DevOps轉型的先決條件,自動化一切可以自動化的,降低部署和發布的難度。 Measure 通過建立有效的監控與度量手段來獲得反饋,推動產品和團隊的持續改進,支持業務決策。 Lean 協作文化,自動化,和有效的反饋,這些實施是個長期的過程,需要以精益的方式小步快跑,對過程與技術進行持續改善。 Culture OKR目標和關鍵成果驅動?建立具有跨職能協作文化和共同目標的一體化團隊;這是DevOps運動的根本! Sharing 不同職能、不同產品之間分享開發和運維過程中的想法,知識,問題,以及失敗經驗,共同提升能力。     Q&A   Q:基于Jenkins的CI/CD不同用戶是怎么管理的??權限怎么控制的? A:在DevOps實施里面提倡充分授權團隊,所以在基礎設施自服務的基礎上讓團隊有自己獨占的Jenkins Master能夠有效的減少權限控制此類問題,同時可以避免不同團隊之間構建任務的相互影響;如果是共用JenkinsMaster,Jenkins有權限控制的插件可以控制用戶的權限。 Q:剛才你介紹的CI整個交付流程,每個細節都需要花大量的時間和精力去開發和實施,如果公司團隊很多,如果分配自己團隊的時間,時間少了自然達不到效果。 A:在實施DevOps轉型過程里面,可以先嘗試試點團隊,通過試點團隊去完成DevOps工具鏈相關的技術選型,在工具鏈成熟的情況下向其它團隊推廣。 Q :請問你們有DevOps的自動化運維平臺嗎?可能是一個Web頁面,把DevOps相關的流程和工具集成在上面,方便管理的同時也方便運維開發一體化操作。這個平臺可能還包括全鏈路檢測系統? A:目前我們公司做的基于容器持續交付平臺主要就是解決此類問題,通過流水線來組織工具鏈,同時對相關的環節進行度量,為避免廣告嫌疑就不便多說。 Q:?你們在這個過程中怎么做溝通管理,以防止因為這造成的對需求理解的偏差等問題? A:這塊更多是團隊的組織結構的問題,有興趣可以嘗試通過看板方法,團隊的各個角色都會基于看板完成迭代的開發,通過看板可以幫助團隊成員之間的溝通和需求確認。 Q:因為很簡單,持續集成持續交付,快速迭代,小步快跑,穩扎穩打,這些都有所有的理論最后都回歸到代碼,所有的變更都回歸到本源代碼的變更,如何保障所有的變更無遺漏,如何保證每一次任務都在正確的代碼基準線上進行,如何出了問題快速反饋到研發第一線,及時終止問題的蔓延? A:這塊其實主要的方式就是基于持續部署流水線的方式,上面分享的時候有提到。通過將流水線通過自動化流水線的方式進行控制,在任何階段出現問題都應該讓流水線失?。ㄩT禁),另外出問題不怕,快速解決問題是關鍵,對于流水線最好可以設置Webhook實時觸發,可以確保當問題出現后,問題代碼的域可以關聯到最近的一次提交。 Q:請問你們容器發布是如何自動區分開發、測試、正式等不同環境的,是否需要人工介入修改應用訪問關系和啟動環境變量? A:目前我們自己持續交付平臺對接不同的容器運行環境(目前主要是Rancher),團隊會對環境進行分類管理,流水線中進行容器部署的時候選擇相應的環境即可;另外由于主要是基于容器在做,所以也對容器鏡像的不同狀態也進行了劃分,并且在多個Registry實例之間進行了流轉,物理隔離了開發,測試以及發布狀態的容器鏡像。人工介入的部分主要是控制鏡像狀態的變化這塊。 Q:Jenkins的Pipeline和普通的Project都可以支持流水線?,2者有區別嗎? A:主要解決的問題就是當構建出問題的時候如何快速定位問題,假如在流水線線中涉及8個階段,如果只是在一個Project中實現,需要開發者花很多時間定位;如果是Build Pipeline的話,則可以很直觀的知道問題是發生在什么階段。...

    Read More

    睿云智合金融科技說:戰略和技術變革下的金融云趨勢

    近年,金融市場競爭逐步加劇,尤其是移動支付、眾籌、P2P、量化投資、智能投顧等新型金融服務的推廣和應用,將整個金融行業帶入史無前例的科技力量之爭。戰略家們預言,不久的未來,所有金融業務必將由科技驅動,金融科技領域將成長出更多明星企業。   在波士頓、麥肯錫等權威咨詢機構近期發布的全球金融科技發展趨勢報告中,金融科技被進一步劃分為幾大技術領域:人工智能、大數據、移動物聯網、云計算、區塊鏈。其中,最為基礎的核心技術,仍是云計算。   云計算作為一切應用系統交付和運營依賴的基礎架構平臺,能否靈活、高效支撐起融合了各種創新技術的業務軟件生產與運維,是傳統金融企業推行金融科技變革必需面對的首要挑戰。   2016年我國金融云IaaS市場整體規模為43.4 億元,預計2017 年將達到63.0 億元,同比增長45.2%,且隨著云市場的發展,PaaS也將逐步成為金融科技平臺建設剛需。之后,金融企業IT架構無一例外,都將構建在云計算技術締造的基礎平臺之上。     近來容器技術高速發展,催生“云計算2.0時代”,為傳統金融企業應對金融科技云計算應用帶來新的機遇和挑戰。從2015年開始,國內主流金融機構已經陸續有先行者嘗試引入容器新技術,提升企業云平臺服務能力。例如: ——國內首家面向市場推出容器云服務的綜合金融集團:中國平安; ——國內首家將基于容器的PaaS平臺落地的股份制商業銀行:恒豐銀行; ——國內首家將容器技術在CI/CD、微服務、混合云管理等應用場景予以全面實踐的金融機構:富德生命人壽; ——國內首家將基于容器的DevOps平臺在生產環境進行部署實施的保險企業:民生保險; ……   這些金融企業無論IT亦或業務發展,在各自領域均走在行業創新前端。他們革故鼎新背后,提供技術支持的團隊,正是推動傳統金融企業提升云計算科技水平、實現IT為業務賦能的金融科技公司——睿云智合。 深圳睿云智合科技有限公司(簡稱睿云智合),創立初期主要專注于金融行業創新業務管理與技術咨詢。在積累了多年金融行業數字化業務轉型、相關創新技術引進服務豐富經驗和客戶資源后,于2015年組建起專業云計算技術服務團隊,率先將容器技術引進傳統金融行業,并迅速在業內樹立起客戶標桿和遙遙領先市場的成功案例。   面對全球科技革新的迅猛趨勢,金融行業將如何發展?在當下和未來之間,金融科技企業該如何平衡自身發展與行業趨勢?我們與睿云智合來一場深刻探討:聚焦金融科技如何幫助傳統金融企業實現數字化業務轉型的戰略目標、以及金融云市場未來的發展趨勢。 ? CSDN:金融與科技的關系歷久彌新,尤其近年受”互聯網+”戰略影響,科技金融呈現爆發之勢。在轉型創新的過程中,金融科技主要為金融企業解決哪些核心問題? ? 睿云智合:過去,金融企業依靠政策優勢、穩固的第三方獲客渠道關系,以及與客戶間不對稱信息交互方式,保障了業務“保守、穩定“的發展格局。   現在,互聯網巨頭和諸多新生科技力量滲入金融領域業務競爭,”互聯網金融“一夜之間打破了整個金融行業的平靜。強大的客戶數據基礎、快速高效的移動互聯客戶溝通方式、更多方便觸發客戶直接交互的銷售場景,都成為了科技新金融天然數字化業務競爭優勢。   所以但凡討論金融業發展,無不聚焦于金融科技、數字化轉型。追根究底,其核心就是要解決IT賦能,支持業務向“以客戶為中心”經營模式實現轉型的問題。   在數字化業務領域,誰能抓住業務與創新技術更多結合點,誰就可能掌握更豐富、更靈活、更優惠的獲客方式及運營能力,從而占據競爭高地。   CSDN:在睿云智合服務過的金融行業用戶中,他們主要面臨哪些挑戰?如何在實踐中解決這些挑戰的? ? 睿云智合:在過去幾年互聯網金融的探索實踐中,傳統金融企業用戶數字化業務創新,常常面臨企業IT架構陳舊、應用系統交付效率無法滿足業務發展需求的困境。因此,改造舊有系統架構,將業務應用系統“云化”,打造更為高效順暢的軟件生產與持續運營平臺,逐步成為諸多金融機構IT基礎能力建設的重要課題。   一些有技術能力、資源實力的大型金融機構,看到金融云市場未來的發展趨勢和市場機會,不僅從自身需要考慮,對新一代云計算架構平臺投入,更借助先行者的技術及資源優勢,向同業進行云計算乃至更多IT能力的輸出。   例如我們第一個客戶,就是在金融行業最早實現容器云服務的平安科技。他們面向市場推出的平安金融云項目,除了將容器云平臺快速對接已有IaaS平臺,提供容器云基礎設施資源全面運營管理能力,還實現了為租戶提供開發測試環境的自助服務,為外部用戶CI/CD流水線提供容器運行時環境,實現持續交付等功能。   此外,平安還逐步將自身一些成熟的企業應用,通過金融云開放,面向同業進行推廣。據平安金融云透露,目前已經簽約了近200家金融機構用戶,這無疑是目前市場上金融企業自身IT能力轉化為行業輸出的成功典范。   另一個具有代表性的,則是將容器可應用場景全面實踐的富德生命人壽。在引進容器技術之前,富德生命人壽已將核心業務系統解耦為六十多個應用模塊,并嘗試系統架構的微服務化治理。這些應用以自研為主,所以隨著系統架構改造,面臨如何大幅提升軟件生產交付過程的自動化管理水平,以及在支撐互聯網應用和大數據應用為主的混合云架構下,如何安全可靠地實現應用持續運帷的困境。   我們為富德生命人壽設計了基于容器的軟件持續交付和系統持續運行PaaS平臺,將混合云管理、CI/CD及開發測試環境自動化、DevOps微服務部署運維等方案均逐一進行了落地驗證,項目成果最終為富德生命人壽基于容器技術的應用模塊快速交付、部署與升級,以及對大數據集群的自由調度和彈性伸縮,提供了全面有效的解決方案。   提到基于容器的PaaS平臺建設,不得不說說銀行業的先行者恒豐銀行?;阢y行業務場景和銀行業的特殊需求,我們為恒豐銀行定制開發了鑒權認證、資源管理、應用編排、彈性伸縮、日志收集、監控告警以及鏡像倉庫可視化管理等一系列PaaS平臺的微服務模塊,實現了容器云平臺對多租戶隔離環境的集中管理。   其中,隔離環境分別對應到某個租戶的特定網絡,單個網絡內部流量采用睿云智合(Wise2C)實現的扁平化網絡方案,網絡之間流量由外部防火墻控制。由于客戶還存在跨網絡部署應用棧的需求,因此存儲必須要基于租戶的粒度,可以實現跨環境共享。我們也為此設計了合適的方案。   實際上,借助容器技術大幅提升云平臺服務能力的案例還有很多,隨著這些項目逐一落地并產生更多的項目成果,我們相信它很快將會成為一個普遍的行業需求。   CSDN:睿云智合在金融垂直領域擁有豐富的行業經驗,是否會將其融入到產品服務的設計中?相關的產品在哪些方面具備亮點,是否已經有成功案例?   睿云智合:過去,”以客戶為中心“(CRM)的經營戰略在金融機構更多只是一句口號,因為客戶信息積累規模和質量均不足,客戶接觸點稀少且頻度低,CRM理念中強調的客戶價值持續挖掘很難體現到業務實踐中去。   到了數字化業務競爭時代,獲客方式和服務模式改變,越來越多客戶數據洞察機會、新客戶接觸點出現在企業面前,客戶洞察結果及相關應用變得日益豐富。令互聯網企業獲利豐厚的CRM應用如客戶忠誠度管理、精準營銷、多產品疊加等,對金融企業終于不再是一句空話。   容器技術貫穿底層基礎設施資源管理、上層應用生命周期管理,是一個使用場景極為豐富、回報價值很高的新興技術。但容器技術應用場景復雜,在持續發展變化過程中具有波動性,使過去一貫保守、且依賴第三方技術服務的金融企業,在計劃將之快速引進落地時存在阻礙。他們需要付出更多學習時間、謹慎選擇新興第三方服務商?;诖?,睿云智合決定用自身經驗幫助金融企業實現轉型。   截止目前,睿云智合累計服務過的金融機構近40個,已經落地的容器項目客戶案例超過十余個,其中近三分之一的客戶已將容器技術應用于生產環境實踐,在IT基礎能力提升 方面取得了顯著效果。     在此過程中,睿云智合技術團隊除了在實施服務能力方面得到了充分的鍛煉,更是在大量實踐基礎上總結輸出了自主容器云平臺產品WiseCloud,在前述項目案例中提及的諸多重要功能均已在該產品中完整體現。   WiseCloud支持Docker、Kubernetes等主流容器調度引擎,也引入Rancher等企業級容器管理平臺,提供開發、測試、發布、持續運營等容器化應用的全生命周期管理。面對多容器集群管理平臺,WiseCloud能提供完善的容器管理平臺基礎性服務,包括容器網絡,存儲服務等,對各種容器集群平臺的資源進行統一抽象。此外,WiseCloud未來將逐步支持行業應用架構和接口標準/規范,比如常用行業應用中間件、基于微服務的行業應用商店、已開發好的行業應用SaaS服務等。 睿云智合智合產品架構圖   目前WiseCloud已經在客戶案例中成功落地,就是上面提到的民生人壽保險容器應用云平臺。在金融行業,這是已知第一個將容器技術應用于關鍵業務系統生產環境的案例。項目實施至今已近1年時間,民生保險的IT團隊從研發到運維,已經適應容器化環境下、高度自動化的DevOps體系,也日益體會到高效開發運帷一體化的好處。目前,民生保險正在內部持續完善該體系的細節管理規范,并計劃逐步將所有IT系統遷移到容器云平臺。   CSDN:目前以容器技術為核心的金融云服務市場競爭非常激烈,其中不乏一些知名度高的強勁對手,與他們相比,睿云智合的優勢在哪里? ? 睿云智合:金融企業在新興數字化業務領域的競爭,必須依賴大量科技力量創新,在產品、客戶營銷模式、服務管理方面建立優勢。要快速建立這種競爭優勢,現階段傳統金融企業的IT基礎架構、治理模式必需順應趨勢進行變革,這正是我們金融科技技術廠商的機會。 ? 然而傳統金融機構的IT架構與IT準則,遠遠復雜過互聯網企業。甚至一些金融機構的IT環境,有各自迥異的特征與個性化需求,這使得由互聯網企業服務領域,轉向金融企業用戶市場的容器技術服務商難以適應。   睿云智合的前身便是專注于為金融企業提供數字化業務轉型以及CRM戰略導入的咨詢機構,?我們從最早幫助金融機構實現數字化業務轉型開始,已專注于服務金融客戶多年,在金融企業用戶需求把握和產品設計方面,有得天獨厚的行業背景優勢。   在組建技術服務團隊的過程中,我們注重選擇和培養那些具備豐富企業服務、特別是金融行業背景經驗的技術人員,在快速積累行業客戶項目實踐中,逐步鞏固和提升我們的專業服務能力。   這種專業性和對行業用戶的深度理解,也體現在了睿云智合容器云產品的規劃設計中。?WiseCloud平臺能同時支持多種主流容器集群編排調度管理平臺,在幫助金融企業用戶規避容器底層框架技術路線選擇風險上,帶來很大靈活性,我們提供給用戶充分技術保障。   CSDN:睿云智合聚焦金融行業的科技服務,可否展望一下關于金融科技領域未來的發展方向,以及睿云智合相對應的公司戰略是如何規劃的? ? 睿云智合:?現在金融企業需要管理的應用系統最多上百個,未來,一個大中型金融機構需要管理的應用系統將成千上萬!作為企業市場競爭最依賴的營銷類系統,產品管理、客戶管理、精準營銷將成金融企業重點投資建設應用項目,它們決定了企業實現差異化經營的競爭力。   在金融科技充分發展的未來,金融機構業務模式和組織形態都將發生巨大變革,大量的運營管理工作將由越來越多的技術手段來替代。屆時,金融企業諸多應用系統將趨于標準化,智能化,粒度更細的微服務化。   不難想象,未來金融企業用戶市場上,眾多中小機構需要成本控制和差異化經營,在有限IT資源投入條件下,具有行業屬性的SaaS或云端應用商店,將使他們采購海量應用系統時大大受益。因此,未來金融云市場必將以IaaS、?PaaS、以及具備行業屬性的SaaS和應用商店等多種形態呈現。   在睿云智合的發展規劃中,除了在PaaS層提供完備的解決方案,公司還將進一步謀求向應用層發展,通過自研及整合優秀第三方金融科技行業應用、金融企業同業輸出應用,搭建這一垂直領域的行業應用商店或SaaS超市,為更多中小金融機構從云端獲得快速、便宜的創新技術與業務服務提供幫助。 ? 現階段,睿云智合主要致力于將公司基于容器的云計算技術服務、及PaaS平臺產品(WiseCloud)推向更多的金融客戶,幫助他們及早打造支撐未來金融科技發展戰略的云計算基礎平臺。   未來,我們則將繼續秉承公司多年理念,幫助金融機構實現“以客戶為中心”的數字化業務轉型和創新科技引進,伴隨客戶成長,將產品和服務線向金融科技更多領域擴充和延伸。...

    Read More

    容器在企業環境落地的實施路徑和關鍵挑戰

    一. 容器在企業的落地場景   6月4號DockerOne Container 大會上,包括來自Docker 平臺產商和Docker 用戶的眾多嘉賓都分享各自的容器實踐, 以及未來的發展趨勢, 其中Rancher Labs 的CEO 梁勝博士分享容器要企業落地的主要場景和實施關鍵,?梁勝博士談到了容器在企業落地主要四種場景: 另外,梁勝博士認為,容器在企業落地,關鍵不是為服務架構, 容器云的建設, 才是在企業落地的關鍵 二. 容器在企業的落地實施路徑   結合Wise2C 過去在金融保險行業容器實踐,選定一個能在企業落地場景非常重要,但同時,也需要注意容器在企業的落地,需要結合自身實際情況有一個逐步推進的過程,要找到一點適合自己的容器實踐路徑。下圖是我們分析了金融保險IT的現狀,提出一個保險行業推進容器落地的實施路徑: 容器過去三年發展非常迅速,但到目前容器主要的用例還是軟件的開發測試環節,Docker 容器技術帶來的一個劃時代的價值貢獻就是解決了軟件和環境的依賴問題,所以docker容器出現后在軟件的封裝和分發應用方面有很多使用案例: 1 推進容器在企業的落地,首先可以考慮在軟件開發和測試環節,利用容器技術,提升和改進現有軟件研發流程,構建或者改進現有的CI 系統.?? 2 其次,可以考慮將傳統應用容器化,?在部署和運維環節解決現有系統的痛點,不要對容器技術過度定位,在網絡和存儲等方面盡量利用現有主機網絡,存儲或者底層IAAS 提供的網絡,存儲服務。 例如考慮是用容器技術來簡化復雜應用的部署,利用容器的服務編排能力,實現應用的一鍵部署.   上述兩個場景,是初次接觸容器技術企業重點考慮的方向 3 對正在規劃建設私有云的企業,可以考慮容器云的建設方案?。 過去虛擬化或者IAAS平臺的建設,解決的是虛擬機等基礎設施資源的快速部署和供給問題,對外提供的仍然是計算,網絡和存儲的基礎設施服務,?但企業內部的開發,測試團隊或者業務部門,往往需要的是一個開發測試環境,業務系統環境,是包括基礎設施以及相關應用等.? 容器云可以提供更細粒度的資源供給同時,可以交付整體應用環境.? 符合云平臺用戶的最終使用需求 4 在熟練是用容器和有良好容器使用實踐的基礎上,企業構建基于容器的輕量級PAAS,?構建企業應用商店,全面監控和管理應用的生命周期。 相比傳統的PAAS平臺,基于容器的PAAS平臺可以為開發和運維團隊帶來更多的靈活性和控制力. 5 如果企業在維護和使用龐大的復雜的單體應用,在推進應用微服務架構轉變時,可以利用容器管理平臺來管理微服務的復雜性。 一個復雜應用拆成多個微服務后,帶來微服務的管理復雜度,利用容器管理平臺,可以為微服務提供資源調度,服務編排,服務監控,服務高可用以及服務發現等平臺服務.? 降低微服務的管理難度. 三、容器在企業的落地的挑戰和風險   目前,容器在各個場景都有廣泛的使用案例,但是作為剛出現的創新技術平臺,如果對docker容器技術沒有很好地掌握,或者過度定位,要把容器在企業落地會存在較大風險.? 這些風險包括 1 ?容器技術的成熟度和對容器的過度定位帶來的技術風險。 目前容器在安全隔離,網絡和存儲等方面還不太成熟,Docker 技術發展非???,Docker 技術生態圈也在快速的推出各種網絡和存儲方案。?企業客戶往往缺乏對這些新的方案實際使用經驗,很難選擇合適方案。另外很多Dokcer 平臺和生態系統廠商容易對容器技術過度定位問題. 2 團隊缺乏容器相關實踐鍛煉,缺乏對容器的正確理解,容易將容器的用法和虛擬機進行比較和對照,在應用封裝,部署,運維和安全管理等方面不能正確使用容器,充分利用容器帶來的好處。 例如, 對于容器的使用,企業IT團隊容易犯的錯誤是把容器和虛擬機進行對照. 再用部署時,往往不會將應用系統拆分應用程序,數據和配置,打包進容器運行,因此封裝,部署和運維等方面不能正確的形成一套機制來充分利用容器帶來的便利....

    Read More

    睿云智合@CCTC 2017 中國云計算技術大會

    國內云計算技術領域最專業、影響力最大的盛會———中國云計算技術大會CCTC 2017,5月18-19日在北京朝陽門悠唐皇冠假日酒店盛大召開。來自海內外的超過60多位講師、以及2000多位云計算專業開發者和相關從業人士參與了此次盛會。 CCTC云計算技術大會,睿云智合展臺前人流如織,展臺大屏幕上循環播放的持續交付平臺Wise Build以及容器PaaS平臺WiseRun的演示視頻引起了很多參會客戶對睿云智合產品與解決方案的濃厚興趣。 容器與運維技術峰會 今天下午,是大數據核心技術與應用實戰、容器與運維技術、Spark 技術、區塊鏈技術四大技術峰會。 深圳睿云智合科技有限公司CTO徐年剛,將在容器與運維技術峰會上為大家帶來以“容器化引領IT新常態”為主題的精彩演講。演講中徐年剛將會就容器技術給云計算帶來創新的理念,區別與過去的虛擬化技術,Application Centirc 的容器技術帶來一些列理念,標準和規范。結合過去在金融保險行業容器技術推廣和落地案例, 詳細分析容器技術在企業傳統應用自動化部署平臺,CI/CD,混合云以及PaaS平臺的應用思路,方法和具體實踐。 演講時間: 5月19日?14:20 ~ 15:10   睿云智合CTO簡介 2002年通過香港專才計劃,加盟中信國際電訊集團,先后任職集團首席系統架構師和國際業務系統技術總監, 集團MIS高級部門總監。后期負責集團云計算規劃和建設,以及利用云計算進行業務創新。 2011 年加入美國Eucalyptus。先后任職美國研發團隊架構師和中國區技術總監,參與國內外多個云平臺項目的交付和管理。 2015年,加入中電科華云,?任職云計算產品總監。推動電科華云加入了openstack 基金會。 2016年以聯合創始人身份加入睿云智合科技有限公司,任職公司技術總監。全面負責睿云的技術路線規劃、產品設計與研發管理。 ? 我們在?CCTC 2017 B006展臺等您! ...

    Read More

    聽睿云智合CTO徐年剛暢談金融行業基于容器技術的DevOps

    9月6日,由深圳金融信息服務協會主辦,我公司(深圳睿云智合科技有限公司)與Rancher Labs聯合協辦的,深圳金融IT界容器技術專題研討會隆重召開并勝利閉幕!會議匯聚了國內外知名的云計算技術大咖,以及招商銀行、平安科技、富德生命人壽、廣發證券等國內金融科技引領企業的容器技術實踐團隊的經驗分享,為150多人的在場嘉賓奉上了一場堪稱金融行業與最前沿容器技術的巔峰碰撞!除了深圳本地的金融行業技術人員,更有來自北京、上海、東北的多家金融機構信息技術團隊積極參與,大家紛紛表示會議干貨多多,收獲頗豐。以下就是小編為大家整理的嘉賓分享內容系列速遞,按照演講順序,今天為大家推出的是來自前Eucalyptus 架構師&中國區技術總監,現睿云智合CTO,國內云計算資深專家徐年剛(Nathan)的分享:《金融行業基于容器技術的DevOps》 究竟DevOps是什么?DevOps是如何促進開發、測試、運維一體化?在企業有哪些實踐?以及DevOps和容器技術有什么關系?CI/CD有哪些常見的解決方案?相信Nathan接下來的分享都會給大家一些重要的啟發。   DevOps 介紹和實踐         首先,Nathan簡單的介紹了軟件產品交付變革。在之前的軟件交付中,軟件的設計規劃,占用的時間都比較長,導致交付到客戶手中的時間就較長。隨著互聯網的飛速發展,現在的交付理念是:小步快跑的方式交付產品,收集用戶反饋,持續對產品進行改進。之前我們更多是在講敏捷開發、而現在更多是DevOps開發運維協作一體化,在企業中已經得到了許多實踐應用。   一 什么是DevOps?     A DevOps是英文Development和Operations的組合 B DevOps是一組過程、方法與系統的統稱:用于促進開發(應用程序/軟件?工程)、技術運營和質量保障(QA)部門之間的溝通、協作與整合,這才是DevOps的宗旨。   二 DevOps企業實踐     DevOps在企業中的實踐主要從四個方面來實施:   持續部署(CI/CD) 度量和反饋(持續運營) 組織協作(建立全功能團隊) 架構解耦(系統解耦,技術解耦)     由于此次研討嘉賓實在大咖,而時間卻有限,所以Nathan這一次先給我們介紹CI/CD。怎么開始CI/CD實踐呢?主要是從以下5個方面。 持續集成/部署流水線 這個環節是怎么樣實現的呢?開發者提交代碼觸發代碼更新,然后自動CI構建,在等待構建成功之后,開始部署和執行自動化功能測試。自動化部署成功之后,觸發手動部署UAT或者生產環境上以及非功能性測試。說這么多,流水線內部是怎么樣的呢?如下圖:   圖1:基本CI構建   圖2:?自動化功能、契約測試   圖3:部署手動測試     那怎樣CI/CD流水線設計才算是好的呢? 可視化:流水線的運行和停止,成功與失敗對所有人直觀可見;通過大顯示器投放給整個團隊   反饋:流水線通過顯示器,短信,郵件等多種手段及時將失敗信息傳達到相關團隊成員   可控制:從構建到生產發布總有一些環節是需要人手動驗證的,比如UAT,發布前的批準等;端到端的流水線需要某些環節可以暫停,等待手動繼續   門禁:流水線中任何一個環節失敗應該讓流水線停下來,并通知團隊,比如自動化測試不通過,Schema升級失敗等   關注度:當流水線發生失敗時團隊必須立刻有人關注并解決它,否則流水線的反饋對團隊的作用就會大打折扣。Time in “Red”是對流水線關注度的一個重要度量指標 內建質量 內建質量即在軟件產生的各個環節中建立固化的、自動化的質量保障體系。 我們來看下一個比較經典的質量控制體系案例: 靜態程序分析 利用代碼分析工具,不執行代碼的情況下對其質量進行檢查,包括重復代碼,安全漏洞,及各種代碼壞味道;   單元測試 直接調用應用代碼,對程序的輸入與輸出,以及執行過程是否符合預期進行測試;單元測試不能僅強調覆蓋率,而要進行評審,保證有效性和場景覆蓋的完整性;   自動化契約測試 系統提供的每一個接口(Web服務,MQ或其他)都是與其消費者所達成的契約,都必須要有對應的自動化測試;   自動化部署驗證 在生產環境部署完成后,通過自動化方法對其部署是否成功,應用和服務的運行狀態進行驗證,以判斷該部署的新版本是否能夠向用戶開放;   自動化界面測試 通過模擬真實人在界面上與系統的交互,對系統的完整業務流程進行驗證;這種測試方法更貼近真實,但執行效率也較低;   自動化非功能測試 非功能測試包括性能測試,壓力測試,安全性測試等,也應當集成到端到端的部署流水線中;不過并非每一個故事或特性都需要非功能測試   基礎設施即代碼 基礎設施即代碼,怎么做呢?腳本化一切可以腳本化的、用版本控制庫管理所有腳本和代碼、禁止人工操作。 構建 利用Shell腳本文件(.sh)或自動構建工具來進行應用和服務的依賴管理,編譯,執行測試,和生成安裝包、部署包。 不同的語言有不同的構建工具,如Java的Maven,Gradle;C/C++/Objective C的gcc, CMake, Ruby的Rake等。   ...

    Read More

    聽廣發證券首席架構師-梁啟鴻暢談容器化與組織結構

    9月6日,由深圳金融信息服務協會主辦,我公司(深圳睿云智合科技有限公司)與Rancher Labs聯合協辦的,深圳金融IT界容器技術專題研討會隆重召開并勝利閉幕!   會議匯聚了國內外知名的云計算技術大咖,以及招商銀行、平安科技、富德生命人壽、廣發證券等國內金融科技引領企業的容器技術實踐團隊的經驗分享,為150多人的在場嘉賓奉上了一場堪稱金融行業與最前沿容器技術的巔峰碰撞!   除了深圳本地的金融行業技術人員,更有來自北京、上海、東北的多家金融機構信息技術團隊積極參與,大家紛紛表示會議干貨多多,收獲頗豐。   以下就是小編為大家整理的嘉賓分享內容系列速遞,按照演講順序,今天繼續為大家推出的是來自廣發證券首席架構師兼信息技術部副總經理?- 梁啟鴻?的分享:《容器化與組織結構》     首先,梁啟鴻先生以新常態與去庫存展開分享,并且結合金融IT以及現在互聯網發展態勢,進行了探討: 對于現在傳統企業的IT架構而言,代碼庫存繁多、雜亂?、變更快,從而導致運維風險大、成本高,從而無法很好的管理這些代碼庫存。很多企業就想抓住這樣技術變革的機會進行彎道超車,就拿如火如荼的金融行業來說,正在緊鑼密鼓的部署著一套套屬于自己的架構體系。 除此之外,梁啟鴻先生還介紹了互聯網區塊鏈中的分布式、去中心化、去庫存的架構。對于這樣的架構我們可能需要用到微服務(微服務架構)。一旦采用微服務,由于生產工具影響生產者關系,容器工具鏈便成了一個重量級的殺手武器容器!   容器化 容器化?– 可能是過去五年來軟件業最重要的“運動”。容器技術的出現其實是一種潮流,一種趨勢,但為什么又要稱之為運動呢? 他改變了我們的交付方式,改變了我們的軟件思維。等到容器工具出現的時候,DevOps才得到真正的發展。 一 理性認識容器化技術   技術問題解決的關鍵,沒有“銀子彈”,容器不是“黑科技” 容器技術,促進了更多新技術發展; 容器工具鏈,促進DevOps; 用容器工具鏈,更便于遵循Micro Service、Reactive、12-Factors 等架構風格、最佳實踐;   容器對你的代碼沒有入侵性– 不會讓系統更快或者更慢;對你的架構有入侵性– 一旦采用你就要走分布式架構。 二 容器出現前后的云計算 容器出現前大家認為云計算是運維人員使用的技術,接觸最多的就是虛擬機。用虛擬機的api與業務應用相結合。這個時期應用架構并沒有受到云計算的影響。而容器出現后,云計算技術向應用轉移,開發者成為它的直接用戶,編排好的容器里的東西運維不需要關注。要用好容器,需要了解好分布式的架構。還用以前的應用架構去搭建是不現實的。       組織結構 影響組織結構的技術、架構理念與技術運動如下: ? 云計算:IaaS/PaaS/SaaS ? 微服務:MicroServices、Containerization ? DevOps:APM、InfrastructureAsCode、ImmutableInfrastructure、ITAutomation…   一 單體架構組織以及微服務架構組織   所謂servlet、mvc這些都是一些傳統的方式。到2013我們開始用這種全棧同構的基礎架構同時走這種微服務方向,你比如像這種電商服務產品中心,購物車,適當性管理形成一些單一的微服務,這些微服務是可以共享這些應用的。 二 Gartner的“內架構”與“外架構”   在Inner Architecture中singleresponsibility這種單一微服務,他的邊界是很清晰的,技術主要聚焦在業務,有時需要2、3個人的小團隊去負責。而outer Architecture,他的可用性、彈性、韌性就只需交給平臺去負責管理即可,它有著強大的監控部署體系同時兼容著PaaS平臺即服務,這也是容器技術出現之后,PaaS變得更可用、更現實,還解決了一些PaaS中出現的繁瑣、碎片化的問題。 三 從Silo型到Matrix型到DevOps型   說到組織結構是從silo型到matrix型到devops型慢慢演變的一個過程。要想建立良好的組織結構,首先需要建立一個平臺團隊,每一個項目以產品經理去驅動。保障交付的時間,不保障交付的功能。對于傳統的流程是從業務的需求,審批,再到硬件的采購,軟件的開發,再測試部署,最后客戶反饋,每一個環節可能是一個禮拜或者一個月,而現有的agile devops則是直接從業務到軟件開發部署,最后反饋,節省了很多時間。 四 原則建議   ? 大系統小做(別想“一口吃個胖子”) ? 小團隊可以做大事情(從電商到交易終端到交易系統,都是幾個人開始) ? 全棧(Fullstack)型技術團隊讓架構更加靈活 ? Conway ‘sLaw(康威定律),不要和它“抗爭”,遵循它 ? Brooks’ Law-技術系統設計的理念,不應該建立在“加人就能增加團隊生產力”這種假設上 ? 利用工具反過來促進持續試驗與學習的文化 五 圍繞OODA閉環的持續交付組織   boyd ?Loop是美國空軍在實戰中觀察總結的決策閉環。后來netflix利用亞馬遜云的ami實現10分鐘級別的更新部署。?代碼越多,bug越復雜,生產環境就越不穩定,形成反脆弱組織的一個期望,我們需要怎么去做呢?就是同一個組織,同一個夢想,同一個kpi,讓開發與運維,同一套工具。 ?   總結 在分享結束之際,梁啟鴻先生還總結了:所有金融系統都是一系列組裝系統,復雜系統是分開人和機器兩個部分的,那么把IT作為一個孵化器,啟動一個快速迭代,快速創新同時能夠支持像OODA閉環這樣的環境,將其應用實踐于業務生產中才是我們真正需要做的!...

    Read More

    聽平安科技資深專家 – 陳春潤暢談平安金融云之CaaS服務建設和應用

    9月6日,由深圳金融信息服務協會主辦,我公司(深圳睿云智合科技有限公司)與Rancher Labs聯合協辦的,深圳金融IT界容器技術專題研討會隆重召開并勝利閉幕!   會議匯聚了國內外知名的云計算技術大咖,以及招商銀行、平安科技、富德生命人壽、廣發證券等國內金融科技引領企業的容器技術實踐團隊的經驗分享,為150多人的在場嘉賓奉上了一場堪稱金融行業與最前沿容器技術的巔峰碰撞!   除了深圳本地的金融行業技術人員,更有來自北京、上海、東北的多家金融機構信息技術團隊積極參與,大家紛紛表示會議干貨多多,收獲頗豐。   以下就是小編為大家整理的嘉賓分享內容系列速遞,按照演講順序,今天為大家推出的是來自平安科技資深專家?- 陳春潤的分享:《平安金融云之CaaS服務建設和應用》 分享開始,陳春潤先生首先從平安云5大特性展開介紹。和現在的公有云服務供應商對比,平安云在系統、合規以及數據方面有著自己的特點。結合平安集團的發展戰略,將平安云平臺定義成具備“專業、增值、可靠、安全與合規”特征的金融云服務供應商。   專業:理解行業特性,利用平安科技多年的金融IT咨詢及研發能力,專業服務于金融行業客戶。   增值:為金融行業客戶提供軟件、數據、網絡、征信等一系列增值服務,構建起金融同業共贏共生的“超級購物中心”。   可靠:利用創新的高可用架構和自動化運維平臺為用戶提供可靠的基礎設施服務打造可信賴的云計算平臺。   安全:打造適合金融行業的安全體系、符合CSA規范的有強防護能力的云計算平臺。   合規:重點研究與監管(一行三會)要求的契合度,成為金融云的標桿,為金融行業客提供合規、便利的一攬子云計算服務。   除此之外,陳春潤先生還表明,平安集團子公司中包含金融行業的各個類別,不同企業、不同來源、不同開發模式的業務系統對底層資源的需求差異很大。所有這些需求對于平安云來說都是必須要滿足的。   因此平安云會為用戶提供不同類型的彈性計算服務,包括: 物理機:高性能,高規格 虛擬機:靈活、安全的共享 容器:靈活、輕量、快速交付   這些不同的計算模式可以共享相同的VPC網絡,用戶可以根據應用架構選擇將一部分應用部署在物理機上,也可以部署在虛擬機上或容器服務中。   容器服務的設計目標 對于容器服務的設計目標,陳春潤先生闡述了2點。 一、對于大多數租戶而言,希望能夠使用容器服務加快環境部署的速度,提高擴容的效率,降低運維成本。 因此,平安云提供一套簡單有效的容器服務產品,使得用戶能夠自助完成容器部署工作。 自助式容器服務(私有或公有云服務) - 用戶可定制容器基礎架構 - 公共鏡像商城 - 私有鏡像管理 - 支持混合部署方式 - 兼容平安云基礎架構 - 兼容平安應用架構規范   二、對于開發團隊而言,希望擁有一套從開發測試到生產部署的流水線,容器服務作為流水線中的實際運行環境,完成最后一公里的工作。 全流程部署自動化(私有云服務) - 提供API與開發管理平臺緊密結合 - 支持開發-測試-生產環境部署流水線 - 用戶可定制容器基礎架構 - 支持“全容器”和“開發測試容器+生產非容器”型部署需求 - 私有鏡像版本管理 - 平臺層服務支持   平安云容器服務架構 容器它有自己運行的方式,不改變任何開發的流程,但是從最終目的來講,開發不改變傳統的架構,容器的功能是很難的發揮的。   平安云統一管理區   我們會有一個統一的綜合管理區,這個區會部署我們一個自己caas服務主體和面對對客戶管理的vpi的部分。 - 容器服務門戶。   - 門戶系統,提供容器服務操作。   - 基于lvs+keepalived部署架構,外接mysql集群。 平安云公共服務區 我們有自己的每個數據中心,整個平臺作為數據中心,每個數據中心內部會有一個資源管理區,這里面會有一些公共的rancher組件,同時支持對每個用戶有單獨? rancher server,這是我們一個比較大的改動,盡量減少管理域,鎖定在一個工作內,這樣我們的風險,控制就會更細。 Rancher 服務 - 核心服務組件,主要用于容器調度與部署。   - 基于lvs+keepalived部署架構,外接Mysql集群。 Docker節點 - 用于鏡像制作、上傳、下載,文件傳輸,執行Docker命令。 Public Registry - 平安官方公共鏡像倉庫,同時是官方公共租戶的鏡像庫。 - 采取多節點掛載共享盤部署。   租戶VPC(某個租戶私有的VPC) - 每個租戶擁有完整容器部署和運行環境,包括Rancher Server、Docker節點、Private Registry。 - 隔離與其他租戶之間的影響,減少跨租戶的網絡訪問。   CaaS核心功能 容器這個概念雖然簡單,但是對于很多開發人員來講,對于他們的要求還是很高的,所以我們把它簡化,形成一個比較容易理解應用管理,服務管理,鏡像管理三大功能,其他高級功能都藏起來,只有資深的管理人員才看的到管理。其它的只是做一些底下的接口之類的。   【租戶+環境+權限】 - 以租戶+環境+角色方式進行權限控制。 - 租戶:一個租戶包含多個環境,由租戶管理員維護。 - 環境:同一類級別的服務集合,由環境管理員管理,包含多個應用管理員。   【應用編排】 - 提供官方編排模板。 - 支持Compose部署,擴展了docker compose。 【服務管理】 - 豐富的服務創建配置:支持服務link、端口配置、環境變量配置、目錄掛載以及資源限制等配置。 - 詳細的服務管理:服務信息、服務事件、服務配置。     【鏡像倉庫】 - 所有租戶共享鏡像商城,每個租戶擁有自己的公共倉庫,租戶內用戶共享租戶內鏡像。 -...

    Read More

    金融IT行業與容器的巔峰對話:聽梁勝博士暢談容器技術未來

    9月6日,由深圳金融信息服務協會主辦,我公司(深圳睿云智合科技有限公司)與Rancher Labs聯合協辦的,深圳金融IT界容器技術專題研討會隆重召開并勝利閉幕!會議匯聚了國內外知名的云計算技術大咖,以及招商銀行、平安科技、富德生命人壽、廣發證券等國內金融科技引領企業的容器技術實踐團隊的經驗分享,為150多人的在場嘉賓奉上了一場堪稱金融行業與最前沿容器技術的巔峰碰撞!除了深圳本地的金融行業技術人員,更有來自北京、上海、東北的多家金融機構信息技術團隊積極參與,大家紛紛表示會議干貨多多,收獲頗豐。以下就是小編為大家整理的嘉賓分享內容系列速遞,按照演講順序,今天先為大家推出的是來自Rancher Labs創始人、CEO梁勝博士的分享:《容器技術發展前景探討》   梁勝博士首先拋出了一個問題點,雖然現在容器技術棧已經非常豐富了。?從最底層的云基礎設施和操作系統到最上層的管理平臺。但是對很多金融企業來說,還是比較難消化的。于是,根據這個情況總結出,在金融企業間的部署和落地主要分2個場景: 應用容器化 企業容器服務   應用容器化主要是將少量容器化應用投產,利用公有云或私有云資源,與CI/CD整合。企業容器服務則是為整個企業搭建容器化應用部署平臺,提高應用開發敏捷性。   雖然,容器技術正在飛速發展,然而,容器技術下一步的發展會在哪里呢?雖然老一代的基礎設施對應用開發還是有一定的束縛性和局限性。但是博士還是強調了基礎設施層的重要性。所以,本次分享博士主要從以下5方面介紹講解與探析。   計算   ARM 依照如今的發展趨勢,計算的范圍比以前的大得多了。脫離傳統的數據中心之后,ARM現在是一個不錯的平臺。ARM給大家的傳統印象是:小、省電。但是現在ARM最新發展,已經從絕對性能上接近intel。   雖然現在ARM服務器還未普及,rancher與合作伙伴docker,已經先于一步在ARM上投試了。 值得一提的是,現在ARM應用在手機上是在pc端上的幾倍。   網絡和存儲   網絡 前幾年因為SDN發展得很快,就形成了一個誤解: 大規模網絡要用SDN和overlay networking搭建。 然后事實是: 許多用戶更喜歡扁平式網絡的簡單,高速,易管理。因為SDN現在帶來2個問題: 加入overlay之后,網管人員不能理解下面的網絡拓撲且原來的網管系統不能運行。 SDN在延時和性能方面有很多差距。 能夠真正的把金融應用做到低延時的物理網絡里面去,雖然有退步,但是加上容器技術。帶來了許多的靈活性。所以,網絡層發生了根本的變化,卻不影響應用層。   存儲 存儲在基礎設施里面是必不可少的一部分。最早的存儲就是毫秒級存取的硬盤。最近幾年發展迅速的SSD的出現顛覆了存儲產業。最令人期待的還是新出現的固態存儲技術,比閃存快幾個數量級?,F在的存儲有2個特征:容量大,速度快,而帶來的問題就是傳統存儲軟件和處理就不適用了。 【主存的技術未來】 【傳統分布式存儲架構】 ceph是非常出名的一款開源容器技術,國內很多開發存儲產商都是基于ceph。但是即使是這么受歡迎的技術,在現在的大變革下,也出現問題。   100,000 個卷?-> 每個卷100 IOPs, 100MB/s -> 總共10M IOPs, 10TB/s   【Fusion-ioHA 架構】 Fusion-io成立于2006年,其創始人當時就認識到旋轉磁盤時代的存儲已經不能滿足現代數據的需求。除了應用加速以外,Fusion的存儲內存平臺還可以降低企業的能耗和總擁有成本。 用一個控制器管100,000個卷??-> 給100,000個卷每個單獨配備控制器   【簡單的Controller/Replica架構】 ?     容器操作系統 現在容器操作系統已經發展成風云群集的時代了,在容器的大舞臺上光彩各異。     在眾多容器操作系統之中,最小的就是rancher os,因此它的優勢就在于:效率高,安全性好。   容器引擎   說到引擎,最著名的就是docker,我們可以看見docker的飛速發展。docker鏡像表格式已經成為一種標準了。     docker引擎分支的零散實現,我們可以看見,Rancher是更新到1.12版本(最新):   容器引擎的解剖:       調度和編排   現在調度和編排系統已經發展成三國鼎立的時代:Swarm、Kubernetes、Mesos。不同的容器編排系統使用因人而異。     對于許多人都在預測,最終三者誰會是贏家,其實這種問題就像js框架的使用一樣,以下是近幾年的js框架的使用情況。   而現在Rancher,所做的就是完整的集裝箱管理。   最后,博士總結了:容器正趕上更新換代的好時機,容器會改變整個基礎設施技術棧,而且,會更快的涌現新的容器技術,所以,你準備好搭上這列車了么?...

    Read More