2016年5月29日 星期日

DevOps Lessons Learned at Microsoft Engineering 筆記

筆記

組織

  • 講Microsoft裡面的DevOps
  • 故事描述的是Cloud & Enterprise and the Bing teams
  • 以前,在一個Feature Team有三種角色:program managers, developers, and testers
  • Developer與Tester在組織架構上就分開,還有一個operations team
  • 我們想要減少內部溝通所需花的心力所以:
    • 結合Developer與tester->software engineer:讓一個feature能從無到有產出並能正確穩定運行
    • 把operations team的人也帶進來->service engineer
  • 要做到最好的單一服務,就是需要一個可以緊密合作的團隊,寫code與測試與運營的人應該要能緊密合作。
  • 最後組織的安排,把dev team與test team結合,operations team也拉進同一個大組織裡。
  • 在這個大架構,接下來就分成Feture team,負責單一個解決方案,Feature,或Product
  • 有專門開發運營內部工具的team
  • 有開發功能的Feature team,由10~12人組成,採用自我組織,自我管理的方式
  • 有4307人在Develper Division,436人在Team Service Team(指的是Visual Studio Team Service),在Team Service Team有35個Feature Team
  • 一個Feature Team有
    • 一個program manager
    • 一個engneering lead
    • 幾個software engineer
    • 幾個service engineer,他們同時支援多個team,但是都在同一個Product裡
  • 另外一個改變就是,相較於之前不同組織就在不同的區域,現在同一的Feture team的人都搬到一起,所以大家不管是討論、接電話,所有有關工作的事情都可以有共同的體驗

責任

  • 上述的所有改變的主要目標就是責任的改變
  • software engineer與service engineer要一起搞出最好的結果
  • 要有量測數據來證明團隊做得好或不好,像是test coverage或是SLA
  • software engineer的責任不再只是把東西做出來,並且還要保持產品的健康
  • 要Feature team的成員對客戶的問題有所洞察,如何讓客戶能很喜歡產品
  • Feature team有完全的責任在產品如何設計開發測試佈署
  • service enginner要更多瞭解他們運營的產品,並提供基礎架構與產品的意見,與部署運營的script or code
  • Automation是Microsoft裡面軟體生命週期與快速產出價值給使用者的關鍵
  • 以前像是,手動測試,環境架設,發行管理,都被自動化了
  • 這樣的運作方式更靈活,也有更多機會可以失敗
  • 因為都做到自動化,Dev可以自己管理Change,並且導入Feature flags,用來減低風險。
  • 導入這些改變之後作者覺得有在Startup的驅動力與興奮感(?)

飛行中(!)佈署

  • 從Visual Studio Team Services到OneDrive iOS App,都用Canary Release (派一隻金絲雀到礦坑裡試試有沒有毒氣),這在VSTS team叫deployment rings。
  • 團隊弄好版本後,經過自動build與test,然後發布到內部測試帳號,或早期體驗帳號,或是developer自己的機器裡。
  • 現在在VSTS team的deployment ring有4個,有12個單位遍布Azure regions
  • 第一個ring是有VSTS帳號的
  • Feature team的lead engineer核准發布的第一個ring,因為在第一個ring的都是Feature team的人,自己先測完之後再自動化發布到其他的ring,如果有問題就自己趕快修。
  • 而大部分的功能都有feature flag來控制
  • 接下來是OneDrive App的例子
  • OneDrive App團隊用VSTS來自動build與test,然後用HockeyApp來發布到ring上
  • HockeyApp可以提供安裝,運行,Crash與使用者統計,目前是用在內部測試的ring
  • 接下來就是用Apple的TestFlight來給beta tester測試
  • 一旦ok了就打開feature flag正式發布給所有使用者

Idea Velocity

  • 有了Continous Delivery,idea可以快速的被評估測試。
  • 在Bing,任何idea都快速的被實驗測試收集統計資料,所以可以比較正確地被評估,這樣更激勵內部人員提出並實行他們的idea

2016年5月28日 星期六

Riot工程師分享:THE ARCHITECTURE OF THE LEAGUE CLIENT UPDATE 筆記


心得

看了這篇才知道可以用CEF來開發Desktop Client,Java Script統一所有前端的浪潮還在持續呀。最後講到了”datacenter in a desktop.”也蠻有趣的,Plugin架構雖然不是什麼新觀念,但卻可以很好的解決他們遇到的問題,以後遇到可以參考一下。話說回來,要寫個windows client要同時寫C++與Java Script,好像有點OOXX,不過這是因為他們不想連遠端Server的實作都改的折衷方案,畢竟Client整修失敗,就把舊的拿出去用就好,Server整修失敗,就….

筆記

  • 主要就是談:the League client update,進遊戲之前的Client Application
  • 原本使用Adobe AIR,使用它的RTMP協定,動畫呈現,而且還是跨「桌機」平台。遊戲推出的當下,可說是很好的解決方案,不過接下來就開始不合時代潮流,因此要做新架構
  • 新架構要解決的:
    1. 用HTML5+JavaScript的解決方案,不管是在client端呈現,或是與Server溝通,還有工作流程與開發環境都比原本更有擴充性且易用。
    2. 不管是遊戲內遊戲外,玩家都可以保持連線:原本Adobe AIR的方案對PC資源使用率過大,也不支援手機。
    3. 工程師們想要有個更簡單一致的開發架構。
  • 一開始想要改少一點,想說直接重用Adobe AIR的code來搞,但發覺現在已經有更多更好的方案。
  • 後來選擇了 Chromium Embedded Framework (CEF) ,寫Desktop Client就像是寫網頁。對HTML 5有很好的支援,而且界面修改自訂可以更靈活。
  • 決定重寫(!),重寫很危險,但好處比壞處多就上。

Step A

  • 所以Client界面主要就是Java Script
  • 為了要讓Java Script與原本的Server溝通,原本Server是支援RTMP,所以他們為Java Script Client開發了一個C++原生Library,負責用RTMP與Server溝通,以及提供非同步的處理。
  • 為什麼Server還是用RTMP?因為不想同時Client與Server。
  • 選擇ember.js當Java Script Client框架,ember-orbit當作資料層
  • 看起來架構還不賴?問題馬上出現了。
  • Java Script Client變得非常複雜,裡面的元件各自處理非同步的部份,使用者的狀態也保留在Java Script Client這一層(!),所以記憶體變得很大。
  • 這個方案解決1.但是2.與3.都沒有處理好,而且Developer抱怨連連。

Step B

  • 開始思考一般Web Application是怎麼做的,反正都用Java Script了,來向一般Web Application取經
  • 發現少了中間層!
  • 所以弄了個C++寫的micro service層,但是在本地端!
  • micro service層就像是http server,按照REST的規則來提供資源存取,讓Java Script Client不要處理非同步(複雜度的主因)。
  • micro service層與Java Script Client層用Web Socket溝通,micro service層與遠端Server還是用原來的RTMP溝通
  • micro service層取名叫Foundation
  • 弄成這個架構之後,精簡掉所有不必要的Java Script VMs,只留下Foundation,Java Script Client都只用GET
  • Foundation大概佔用20MB記憶體,玩家不需要把Java Script Client砍掉才進LOL裡面!
  • Foundation可以用system tray來呈現,不管玩家有沒有打開LOL都可以接觸到遊戲資訊。

Step C

  • 換成新架構後,寫功能就是要寫micro service與遠端server,micro service與Java Script Client。
  • 大家都改同樣的地方,互相影響。
  • 需要架構上的解決方案來讓團隊協作更有效率。
  • 作者自己研究了許久,決定採用Plug-in架構
  • 每個Plug-in必須有自己的Semantic Versioning,還有它依賴哪個Plug-in與這個Plug-in的Semantic Versioning。
  • 把架構呈現成Graph的形式,Plug-in的相依性一目了然
  • 所以有front-end (FE) plugin,用Java Script,實作UI。有back-end (BE) plugin,用C++,實作資料處理與遠端Server溝通。
  • 取名叫Front-end與Backend是代表這個架構模仿所謂的Client-Server架構
  • 用Plug-in可以簡單開關使用者可用的功能,通常是不同區域的使用者。
  • 由於之前用ember-orbit,Front-end還是可以直接操作很多資料,又增加複雜到,所以讓ember-orbit退休,資料都透過REST從back-end plugin拿,front-end plugin可以快取資料,但其他複雜資料的處理就不要在Front-end了。

Step D

  • 已經有了更有生產力的架構,大家可以各自做自己的Plugin不會互相影響。
  • 有些人不喜歡Ember.js,想直接用HTML 5的東西。
  • 有些人在別的地方已經有了現成的Web Client,想說直接搬到這個Java Script Client,這樣就不用重作一次Client,反正都是Java Script。
  • 本來很堅持來這邊開發就一定要用Ember.js,後來發現,就算每個Plug-in都用Ember.js,要保持每個Plug-in的Ember.js的版本相同,也很困難,公司太多Developer了。
  • 最後改成每個Plugin都可以用自己的Java Script Framwork

結論

  • 最後的架構,可以讓多個團隊獨立的開發the League client update,HTML5 Front-end與C++ back-end的配合夠靈活效能也夠好。Plug-in架構不只對開發有幫助,對實際產品呈現也有幫助。
  • 大部分人都很滿意!
  • 回頭來看,這就是一種”datacenter in a desktop.”的架構,Atom就是如此。
  • 還有HTML視覺效果,功能可以獨立更新發布還沒講。

2016年4月18日 星期一

微众银行基于自主可控技术的分布式架构实践

參考來源:微众银行基于自主可控技术的分布式架构实践 http://www.infoq.com/cn/presentations/webank-distributed-architecture-practice-based-on-self-controlled-technology

心得

難得看到新銀行的案例分享,新銀行就沒有過去技術的包袱,每個邏輯節點可以作所有業務,但把user分塊,也就是沒有一個資料庫有全部的資料,不同節點之間需要對方的資料就要去查詢。並且同時有Scale up與Scale out的方案,把模組切分的更獨立來架構變得靈活,用Open Source技術與同一機器環境讓運營成本比起傳統銀行少了10+倍。非常值得參考!

筆記

  • 普惠金融:普惠金融體系(Financial Inclusion System)普惠金融體系是指一整套全方位為社會全體人員,尤其是金融弱勢群體提供金融服務的思路、方案和保障措施等。
  • 去IOE:(去掉IBM的小型机、Oracle数据库、EMC存储设备)
  • 微眾銀行WeBank,全虛擬化銀行。開發時間很短,30億資本,半年籌建。
  • 選擇自主可控全分布式架構
  • 分散風險的進化,目前一般銀行的架構是集中式鬆耦合,同一個業務由一個節點或是多個節點服務,但業務之間還是緊耦合,所以只要某業務所屬節點有問題,還是會造成其他業務出問題。後來進化成一個節點包所有業務,但是只服務特定客群
  • 提高冗餘的進化:一般銀行多主節點,沒辦法滿足CAP。最後捨棄高性能,一主兩從,
    取CP
  • 進化後:一個節點是一個邏輯概念,可以做同一客戶群的所有業務,有多台機器,一主二從架構的保持資料一致性與備份。
  • 把服務分成兩大類,對客戶,對內部後台管理,所以有兩種類型節點
  • 一個客戶的業務在一個節點上處理,一個節點可以處理多個客戶,一客戶一開始就指定在哪個節點,客戶創立與查詢用GNS(客戶在哪裡)來做。
  • 雙向擴展
    • 橫向擴展:客戶變多加節點
    • 縱向擴展:同樣的客戶業務變多,升級機器,或是增加節點的機器數量。
  • 規則:客戶變多只能用橫向,一節點五百萬就是五百萬。
  • 分佈式架構平台,參考圖,業務能力、基礎能力(無狀態服務,大數據框架)、基礎資源(資料中心,虛擬機器,網路)。
    這個架構其他業務也可以參考。
  • 所有節點不共享網路、服務器、數據庫存儲。
  • 選擇開源技術與低端服務器,才能做到。
  • 組件都很簡單,一個組件只做簡單的一件事,後續管理才會簡單
  • TDSQL:腾讯云金融级数据库CDB for TDSQL (Cloud DataBase for Tecent Distribute
    SQL)是一个适用于OLTP场景且与MySQL 5.5 、5.6兼容的分布式关系型数据库。
  • OLTP:所謂線上交易處理(OLTP),其英文全名為On-Line Transaction Processing,是傳統關聯式資料庫(Relational Database)之主要應用,係指基礎性的日常事務處理,故算是面對交易的處理系統。
    我理解是即時支援Transation
  • 100+ x86伺服器,用簡單同一的機器,作邏輯分資源模塊。
  • 有網關來限流,讓資料百分百不遺失
  • 通常對於效能的取捨就是性能,需要性能就加機器。
  • 用硬體作Message Queue管理。對於100bytes的message可以做到每秒3500萬筆,確保送達模式就每秒10萬筆
    嚇死人,用硬體作Message Queue第一次聽到
  • 用硬體作Message Queue,就沒辦法加上更多邏輯的實作,反而讓各功能component變得簡單。
  • 全部都用open source
  • 一般銀行一個帳戶20~100元/年,微眾一個帳戶5~3元/年
    省很大!
  • 去IOE,讓大象瘦身可以跳舞。性能無限擴展(!)

2016年3月14日 星期一

筆記:Akka Streams: Streaming Data Transformation à la Carte

心得

這位Viktor Klang講話方式與外型都很像我前同事XD,現在Akka除了可以提供不用管Thread的執行模型之外,還有Akka Stream可以提供處理資料的模型。其實我對Akka沒很熟啦,不過因為後來都是在寫Backend的關係,所以對Backend處理架構有興趣。看起來Akka Stream除了提供原本基於Actor的好處之外,還提供了對資料流更高階更有效率的抽象化架構,像是Source, Flow, Sink這樣的概念,以前在做M$的DirectShow就有接觸了,不過那個只是單機視訊播放。這個是處理數千數萬的資料流,應用的等級差很大。最後帶到Reactive Stream的概念,那個Dynamic Push-Pull Model看來真的是蠻屌,但應該還在發展中。話說現在typesafe也要改名成lightblend了,看來他們公司搞的技術都頗有看頭,希望他們Live long and Prosper!

筆記

簡介Akka

  • Akka: Simple message-oriented programming model for build reactive applications.
  • 會用Scala demo因為可以顯示比較完整(!)
  • 不需要考慮Share state, memory visibility, threads, locks, concurrent collections, thread notifications.
  • 高CPU使用率, 低延遲, 高輸出, 有彈性
  • Supervisor hierarchy可以讓application有彈性
    • 有個root actor當supervisor,管控其下的child actor,有問題就換掉,做得慢supervisor就找其他actor幫忙。
      這種是製造業思維,被敏捷洗腦的我聽了有點OOXX,不過Akka處理message就是製造業沒錯啦…
  • Akka的計算單位稱為Actor
  • Actor有address, mailbox, current behavior, local storage
  • Actor週期性的送出message
  • 每個Actor有一個Parent,由Parent處理該Actor失敗的情境
  • 每個Actor有1..N個child Actor
  • 沒做事的Actor不會佔用CPU時間
  • 一個Actor一次只處理一個message,避免Concurrent issue
  • 一個Actor佔用450 byte,所以一台機器可以有百萬個Actor(!)
  • Akka Cluster可以有2500個node,所以如果都是10G RAM以上的機器,可以有到兆等級的Actor(!)

    Akka Stream

  • 有誰敢說自己Multi Thread的實作100%正確呢?就算有Test,Multi Thread這件事本質上就是容易錯,我們有一定要用這個作業系統特性嗎?
  • 如果有更簡單的方式,是否可以不用Thread
  • Akka Stream特性:
    • immutable,Actor處理方式讓各個資料流不互相干擾
    • reuseable,有Immutable就很容易可以做到
    • composable,既然可以reuse,就可以很容易組合
    • coordinated,Actor的Supvisor架構
    • asynchronus,Actor是message driven,可以做到非同步
    • transformations,提供各種不同的Transformation方式來處理Flow
  • Linear transformation
    • Source
    • Sink
  • Non-linear transformation
    • Fan in
    • Fan out
  • Non-linear transformation:可以建構Graph,拿來做Protocol
  • 擴展
    • Akka TCP stream
    • Akka Http
    • Reactive Stream Inter op
    • …其他
  • Materialization具體化
    • Akka Stream把what與how分離
    • Source/Flow/Sink的DSL可以建立藍圖
    • ActorFlowMaterializer把藍圖用Actor執行
  • Demo: 定義Source, Flow, Sink形成資料流處理的管道
  • Klang’s Conjecture: “If you cannot solve a problem without programming; you cannot solve a problem with programming.”
    本日學到的名言
  • 比較Push與Pull的特性,主要就是Push沒辦法處理Drop,Pull會有多的Overhead
  • 比較Push&Pull與Supply&Demand
  • 2-way在Publisher與Subscriber
  • 如果我們的Data Flow可以同時有Push與Pull?
    • 當Subscriber比較快就用Push
    • 當Publisher比較快就用Pull
    • 自動切換Push與Pull->Dynamic push-pull
    • 當可以有批次的Demand,就可以有批次的動作,設計者決定要累積多少的Demand才發出信號進行動作。
  • 帶出Reactive Stream,可以完成以上的model
  • 推廣時間:

2016年3月13日 星期日

筆記:Easier, Better, Faster, Safer Deployment with Docker and Immutable Containers


心得

這篇也算是Docker官方業配文?這位法國來的Jerome Petazzoni講英文我意外蠻好懂的。所謂Immutable這個概念最常就是拿人體的細胞來比。聽起來是很有說服力啦。基本上這樣子的Deploy方式就很像修車模組化整批換掉,而且軟體是虛擬的,完全不會有什麼零件製造品質問題或是什麼物理性問題。而這個架構可以強迫設計者把Storage與Service分開,讓Service成為真正的Stateless,而Data與Service分開的速度部份,我覺得也不用擔心,現在幾乎所有雲端Solution都有Storage Service了,怕延遲就是要用In Mem Cache。我最驚豔的是,有side kick container這種東東呀!裝個Container在正在運作的Container旁邊就可以偷看網路與其它東西…Docker真的是越來越成熟了!不過缺點就是,幾乎什麼都要寫code,想要完成這樣子的架構就是要寫一堆configuration!然後就有比較高的學習曲線,然後就要引進版本管理機制,然後就要管理這些東西的複雜度,然後就要找更厲害的Engineer才能把東西搞好搞大!這樣其實對我們來講是好事啦!在IT界總有新觀念可學習,新東西可以玩~

筆記

Never change what’t on a server

  • 不要裝新的packages
  • 不要upgrade原來的packages
  • 不要移除或down grade原來的packages
  • 就算有安全性問題!
  • 不要編輯configuraiton files
  • 不要更新application的code!

如何upgrade

  • 起一個全新的Server然後測試過沒問題之後換掉舊的
    那新舊Server可以同時存在,寫DB怎辦?這可能又是一個只新增欄位與換Data Model才能解決的問題
  • 避免server confiugration drift導致難以維護的結果。

    導入Immutable Server的佈署概念

  • 一陣子就重新換Servers
  • 維護Golden image,所有的Server都用這個image佈署

    缺點

    小修改很可怕

  • 小修改就要把整個Server群的image換掉
    • create image要時間
    • 重新啟用同數量的server要時間
    • 把舊的Server的Request導到新的也要時間
  • 解法:
    • 全部都自動化
    • 用中間image減少編譯時間

      很難Debug

  • 沒裝tcpdump或iptables怎辦
  • log怎麼導出去
  • 解法:把需要用的工具裝進去image裡面
  • 解法:把log導到外面。

    存資料

  • Immutable沒辦法存資料
  • 解法:不要存在Server上,存在其他Storage,Amazon RDS
  • 解法:存在外部系統

    導入Immutable Container也就是Docker

  • Create docker image可以有snapshot,所以小修改要create image更快。
  • 換Image後啟動速度比一般VM快非常多!完全不能比!
  • 可以重使用原本在Host作業系統上的資料,或是用Data Volume Container。
  • Container之間可以分享:
    • 目錄,像是Log
    • 網路,可以用B Container來看到A Container的Traffic!這種叫做side kick container
  • 執行Service的Container完全可以是Read only

筆記:Microservices and the Art of Taming the Dependency Hell Monster

InfoQ辦的2015 QCon,裡面的Session都很不錯呢!這次看的是:
Microservices and the Art of Taming the Dependency Hell Monster

心得

Gilt是在歐洲美國都很有名的線上購物網站,尤其是折扣商品的銷售很猛,雖然我沒買過啦。看他們完全導入Micro Service的數量很驚人,而DB的選擇方式也是相當多元,基本上就是歷史因素以及各取所長。還有就是在Gilt裡,Play+Scala幾乎都是主流了!聽了這場,我覺得學Functional還是應該學Scala啦!裡面講到的Dependecy問題非常有感覺。只要軟體複雜度到一個程度,一定會出現這種問題,還好他們已經先把戰略佈置成Micro Service的形式了。各各擊破比起所有Application或Service大一統簡單。但Micro Service要能減緩Dependency Hell還是要靠REST Service,裡面提出的策略非常有用。就算是想用Remote API Call,這場Session也派的上用場。把Document當成一個產品,放到軟體生產流程裡面成為一個不可或缺的環節,這樣可以完全避免掉Document更新跟不上實作的問題!

筆記

  • Gilt從Ruby+Memchache->PostgreSQL to Play+Scala->MicroService+Scala->Legacy Service->PostgreSQL
  • Micro Service 156+個,Application Service 5~9個。
  • User service, 百萬user,10000 request 1秒,用mongo db(CP)存,有consistency
    • 用Remote API呼叫,回傳Future!可以這樣用喔?
  • Catalog Service, 取所有product,5000 request 1秒,用postgreSQL(CA),百萬product
  • Inventory Service,檢查庫存,與其他domain隔開,10000 request 1秒,用hbase(CP),每天更新一次庫存,需要保證不會多賣。
  • Cart Service:處理購物車,處理量較小,用dynamoDB,用了7年,可選consistency。
  • 從2008~2015年,每個Service的發展速度都不同,所使用的library演進也不同,但是都透過Http提供服務
  • 看起來戰略規劃得很好,但是隨著產品越做越複雜,直接面對User的Application Service也變得複雜,需要包含user service, catalog service, inventory service, cart service等等在一個頁面呈現,結果就是,要把幾乎所有的client library包含進來。
  • 接下來就是
    • 開發application service變得很慢
    • 只要一點小變化就做一個新的client library->因為不想包含太多
    • 做custom API避免包含太多client library
    • 大量相同架構的程式碼,因為想避免client libary dependency
    • Code的品質變差,讓開發變慢
    • 最後就會真正在產品上看到錯誤:java.lang.NoSuchMethodError,哈哈
  • 怎麼辦?從Open Source借鏡
  • http://www.apidoc.me/ 自動產生document

API design must be First Class

  • protocol buffer, api doc就是一種契約,尤其是可作完就丟的micro service,這樣的靈活度就是來自於訂立良好的契約。
  • 這樣的方式就是”Schema First Design”,Server Client就看資料是什麼就怎麼處理。而不要關心其他實作細節。
    這看來有點不敏捷…不過Gilt的code base已經累積很多,不是說改就改,而以micro service的形式,還是可以把改動的影響範圍縮到最少,並且也有可能以敏捷的方式開發。
  • 定義REST API就要遵守REST的語意

Backward and Forward Compatibility

  • 向前相容,新增欄位只能是Optional或是有Default Value
  • 向前相容, 不要Rename!如果真的有需要的話,導入新的Data Model並且提供Migration機制。
  • 向後相容,小心使用Enum,像是他們用Scala定義Enum時會一定要有個Undefined,把處理未知enum的責任交給Micro Service開發者,而不是由不知道實作的Micro Service使用者負責。

Accurate Documentation

  • 他們發現唯一可以讓Document精確的方式就是在Software Process裡使用Document。
  • 用Sematic Versioning,X.Y.Z,當API有不向後相容時,X請進版!

Generated client libraries

  • 有爭議,但他們覺得有用
  • 為了避免寫重複的code,例如發http request,組json
  • 有了Data Schema,API doc,是可以產出Client libary
  • 最小dependency,頂多是包含處理http與處理json的library
  • 為有用到的語言產一個,例如Ruby client library,Play client library等等
  • 產出來的client library只要有通過自動測試,使用者就可以拿去用!
  • 使用者可以從client libary選擇他要用的版本。

DevOps Lessons Learned at Microsoft Engineering 筆記

原文: https://www.infoq.com/articles/devops-lessons-microsoft 筆記 組織 講Microsoft裡面的DevOps 故事描述的是Cloud & Enterprise and the Bing ...