2018年下半年的技術(shù)雷達(dá)發(fā)布了【瓢Γ看過的朋友可能和我的感覺一樣墙基，會(huì)發(fā)現(xiàn)大部分條目都是和微服務(wù)和 DevOps 相關(guān)，但這些條目散落在不同的象限里添谊。本文將這些散落在不同象限的條目采用以下 5 個(gè)主題進(jìn)行重組：
- DevOps 合作新實(shí)踐
- 云計(jì)算新實(shí)踐
- 容器新技術(shù)
- 微服務(wù)及其誤區(qū)
- 安全
特別要提出的是财喳，這期技術(shù)雷達(dá)采納了 2018 年的 DevOps 報(bào)告 中的四個(gè)關(guān)鍵指標(biāo)(FOUR KEYMETRICS):前置時(shí)間，部署頻率，平均恢復(fù)時(shí)間(MTTR)和變更失敗百分比耳高。而這四個(gè)關(guān)鍵指標(biāo)也是業(yè)界度量 DevOps 效果的統(tǒng)一方式扎瓶。
每個(gè)指標(biāo)都創(chuàng)造了一個(gè)良性循環(huán)，并使團(tuán)隊(duì)專注于持續(xù)改進(jìn):縮短交付周期泌枪，減少浪費(fèi)的活動(dòng)概荷，從而使你可以更頻繁地部署，進(jìn)而改進(jìn)他們的實(shí)踐和自動(dòng)化流程碌燕。通過更好的實(shí)踐误证，自動(dòng)化和監(jiān)控可以提高你從故障中恢復(fù)的速度，從而降低故障頻率修壕。
DevOps 的合作
如何更好的在組織內(nèi)合作是 DevOps 實(shí)踐中永恒不變的的話題愈捅。隨著 DevOps 合作理念的深入，合作的范圍越來越越廣慈鸠，隨之帶來了新的問題和挑戰(zhàn)蓝谨。這期的技術(shù)雷達(dá)介紹了以下幾方面的合作：
- 和外包團(tuán)隊(duì)/供應(yīng)商的 DevOps 合作
- 和用戶/客戶/UX設(shè)計(jì)師的合作
- 分布式團(tuán)隊(duì)之間的合作
和外包團(tuán)隊(duì)的 DevOps 合作
而隨著 DevOps 應(yīng)用的加深，會(huì)不可避免的碰到組織結(jié)構(gòu)上帶來的問題青团。特別是和外包方的合作譬巫，會(huì)影響組織的 DevOps 表現(xiàn)。這樣的合作往往充滿了漫長繁冗且火藥味十足的會(huì)議和合同談判督笆，這是 DevOps 運(yùn)動(dòng)中不希望看到的但是又無法避免的問題缕题。在 2018 年的 DevOps 報(bào)告中看到外包會(huì)帶來效能下降——“低效能團(tuán)隊(duì)將整部分職能進(jìn)行外包的可能性幾乎是高效能團(tuán)隊(duì)的 4 倍，這些 外包功能包括測試或運(yùn)維等等胖腾⊙塘悖”
看到這里，千萬不要得出“不要用外包的結(jié)論”咸作。這里說得是不要“職能的外包”锨阿，而“端到端的外包”（End-2-End OutSourcing）則會(huì)免除這種顧慮。很多業(yè)界一流的 IT 服務(wù)企業(yè)都提供端到端的 IT 外包服務(wù)记罚，你只需要告訴它們你要DevOps墅诡，它們會(huì)用最有效的方式交付給你。與供應(yīng)商一起增量交付(INCREMENTAL DELIVERY WITH COTS (commercial off-the-shelf)) 就是這期技術(shù)雷達(dá)中提出的和外包商一起進(jìn)行 DevOps 策略之一桐智。與供應(yīng)商的做端到端的 DevOps 性質(zhì)的外包另外一個(gè)優(yōu)點(diǎn)則是這樣的供應(yīng)商適合做“長期合作伙伴”來補(bǔ)充你業(yè)務(wù)末早、IT 等多樣性的不足，甚至能夠幫你培訓(xùn)員工说庭。
而隨著組織開始采用四個(gè)關(guān)鍵指標(biāo)然磷，這對(duì)對(duì)供應(yīng)商的要求也越來越高，但盈利空間相對(duì)越來越小刊驴。和任何行業(yè)一樣姿搜，成本的降低和效率的提升永遠(yuǎn)是不變的主節(jié)奏寡润。外包也要提升自己的能力水平以跟上技術(shù)發(fā)展的節(jié)奏，這是不可避免的成本舅柜。
但是梭纹，和外包方的合作仍然是在 DevOps 轉(zhuǎn)型過程中不可避免的痛苦，可以采用一些方式減輕這種痛苦致份。例如這期技術(shù)雷達(dá)中介紹的“風(fēng)險(xiǎn)相稱的供應(yīng)商策略(RISK-COMMENSURATE VENDOR STRATEGY) ”变抽，它鼓勵(lì)在高度關(guān)鍵系統(tǒng)中維持其供應(yīng)商的獨(dú)立性。而那些相對(duì)不太重要的業(yè)務(wù)可以利用供應(yīng)商提供的成熟解決方案氮块，這可以讓企業(yè)更容易承受失去該供應(yīng)商所帶來的影響瞬沦。這不光是說 IT 產(chǎn)品供應(yīng)商，同樣也指的 IT 服務(wù)供應(yīng)商雇锡。
“邊界購買（BOUNDED BUY）”就是這樣一種實(shí)踐，在采購產(chǎn)品中即只選擇模塊化僚焦、解耦的锰提，且 只包含于單一業(yè)務(wù)能力(Business Capability)的限界上下文(Bounded Context)中的廠商產(chǎn)品。應(yīng)該將這種對(duì) 模塊化和獨(dú)立交付能力的要求芳悲，加入對(duì)供應(yīng)商選擇的驗(yàn)收標(biāo)準(zhǔn)中去立肘。也可以將一小部分業(yè)務(wù)的端到端維護(hù)外包出去，在獲得靈活性的同時(shí)名扛，又獲得高效谅年。
和 UI 的合作 ——DesignOps
DevOps 的目標(biāo)就是盡可能的縮短最終用戶想法到代碼之間的距離，避免傳遞過程中的信息失真肮韧。特別是用戶的反饋融蹂，于是有了 DesignOps 實(shí)踐。這個(gè)領(lǐng)域的實(shí)踐和工具也日漸成熟弄企。這期的技術(shù)雷達(dá)介紹的一整套支持 UI 的開發(fā)環(huán)境(也稱為UI DEV ENVIRONMENTS)專注于用戶體驗(yàn)設(shè)計(jì)人員與開發(fā)人員之間的協(xié)作超燃，例如 :Storybook ，react-styleguidist拘领，Compositor 及 MDX意乓。這些工具大部分圍繞 React 的生態(tài)圈產(chǎn)生。既可以在組件庫或設(shè)計(jì)系統(tǒng)的開發(fā)過程中單獨(dú)使用约素，也可以嵌入到 Web應(yīng)用項(xiàng)目中使用届良。
分布式團(tuán)隊(duì)的合作
隨著組織的擴(kuò)大，分布式的團(tuán)隊(duì)是一個(gè)無法回避的問題圣猎。你很可能會(huì)和不同地理位置的其它同事一起開發(fā)士葫，例如：不同的辦公樓，不同的城市送悔，甚至是不同的國家为障。但這些問題不是 DevOps 的阻礙，可以通過一系列的工具來彌合地理上的界限。
Visutal Studio Code 目前是最受歡迎的編輯器和開發(fā)環(huán)境鳍怨。而 VS Live Share 給分布式的跨地域協(xié)作開發(fā)的能力呻右，它是用于 Visual Studio Code 與 Visual Studio 的插件。提供實(shí)時(shí)合作編輯與調(diào)試代碼鞋喇、語音通話声滥、共享終端和暴露本地端口等功能，能夠減少遠(yuǎn)程結(jié)對(duì)編程時(shí)遇到的障礙侦香。開發(fā)人員可以在使用Live Share 協(xié)作時(shí)沿用自己的編輯器配置落塑，包括主題、快捷鍵和擴(kuò)展罐韩。
云計(jì)算新實(shí)踐
如果你仔細(xì)看技術(shù)雷達(dá)憾赁，這期的技術(shù)雷達(dá)把 AWS，Azure 和 Google Cloud Platform 這三個(gè)世界上最大的云計(jì)算供應(yīng)廠商放到了 Trail（試驗(yàn)）象限散吵。這說明在采用云計(jì)算的時(shí)候龙考，需要注意防止被云供應(yīng)商綁定。從這個(gè)角度來說矾睦，Kubernetes 這樣平臺(tái)無關(guān)的技術(shù)要更好晦款。
設(shè)置多云賬號(hào)(MULTI-ACCOUNT CLOUD SETUP)可以避免被單一的云供應(yīng)商綁定，可以平衡的結(jié)合采用多個(gè)云平臺(tái)的優(yōu)勢來動(dòng)態(tài)的配置你的云計(jì)算經(jīng)驗(yàn)枚冗。
CHAOS KATAS 是一項(xiàng)為基礎(chǔ)設(shè)施和平臺(tái)工程師提供技能培訓(xùn)和提升的技術(shù)缓溅。它將 Kata （我個(gè)人更傾向于把 Kata 翻譯為 套路）的方法論與Chaos Engineering 的相關(guān)技術(shù)(具體指在受控環(huán)境中模擬故障和停機(jī))進(jìn)行結(jié)合，對(duì)工程師進(jìn)行系統(tǒng)化教學(xué)和培訓(xùn)赁温。這里的 Kata 是指觸發(fā)受控故障的代碼模式坛怪，它允許工程師發(fā)現(xiàn)問題，恢復(fù)故障股囊，開展事后分析并找到根本原因酝陈。工程師通過重復(fù)執(zhí)行Kata能幫助他們真正掌握新的技能。
用基礎(chǔ)設(shè)施即代碼提升基礎(chǔ)設(shè)施的質(zhì)量
管理云計(jì)算資源最有效的形式是采用基礎(chǔ)設(shè)施即代碼技術(shù)毁涉。在這一方面沉帮，早期的 Chef，Puppet 已被 Ansible贫堰、Salt 等取代穆壕。而后繼之秀 Terraform 則簡化了很多的云計(jì)算平臺(tái)上的基礎(chǔ)設(shè)施配置工作。現(xiàn)在其屏，Terraform 已經(jīng)成為公有云基礎(chǔ)設(shè)施即代碼的第一選擇喇勋。這期的技術(shù)雷達(dá)介紹了Terragrunt，它是Terraform 的一個(gè)輕量級(jí)的封裝偎行，用來落地《 Terraform: Up and Running 》書中主張的實(shí)踐川背。當(dāng)然贰拿，在采用它之前你可以先讀一下這本書。
如果你使用了 AWS熄云，并且向通過編程的方式生成基礎(chǔ)設(shè)施即代碼膨更。你可以使用Troposphere，Troposphere 是一個(gè)Python 庫缴允，可以使用 Python 代碼生成 JSON 格式的 CloudFormation 描述荚守。這樣的代碼的復(fù)用性和設(shè)計(jì)都會(huì)很好，同時(shí)它也有類型檢測练般、單元測試以及 DRY 組合 AWS 資源等功能矗漾。?
在云原生的環(huán)境下，跨平臺(tái)薄料，跨實(shí)踐的基礎(chǔ)設(shè)施即代碼技術(shù)將成為下一個(gè)基礎(chǔ)設(shè)施即代碼的發(fā)展方向敞贡。Pulumi就是這樣一款“云原生即代碼”工具，它提供了一個(gè)云原生開發(fā)平臺(tái)摄职，為所有的云原生應(yīng)用通過一致的編程模型和統(tǒng)一的DevOps實(shí)踐誊役，幫助團(tuán)隊(duì)大幅提升生產(chǎn)力，并以很快的速度將代碼遷移到云中琳钉。
結(jié)合往期的技術(shù)雷達(dá)，可以看出蛛倦，在有效的采用基礎(chǔ)設(shè)施即代碼的技術(shù)上歌懒，除了版本化和自動(dòng)化以外，基礎(chǔ)設(shè)施即代碼正在向可測試性和合規(guī)性的方向發(fā)展溯壶。對(duì)基礎(chǔ)設(shè)施質(zhì)量的度量和檢測可以通過基礎(chǔ)設(shè)施即代碼來實(shí)現(xiàn)及皂。而除了公有云平臺(tái)，很少可以見到企業(yè)對(duì)私有的基礎(chǔ)設(shè)施質(zhì)量的關(guān)注且改。和軟件產(chǎn)品一樣验烧，基礎(chǔ)設(shè)施也會(huì)存在技術(shù)債，而這些技術(shù)債會(huì)引發(fā)應(yīng)用程序的技術(shù)債的連鎖效應(yīng)又跛。比如碍拆，你采用了老舊的設(shè)備和老舊的操作系統(tǒng)，在缺乏管理的情況下慨蓝，網(wǎng)絡(luò)感混、安全甚至是性能問題越來越凸顯，而系統(tǒng)會(huì)越來越脆弱礼烈。
Kubernetes 和容器
Kubernetes 已經(jīng)是容器生態(tài)的核心弧满，因?yàn)槌?Docker 以外，還有其它的替代容器方案可以選擇此熬。但編排方案的選擇卻不會(huì)太多庭呜。為了保持容器鏡像的大小滑进，大家往往會(huì)采用 Alpine 和 Busybox 這樣袖珍的鏡像作為基礎(chǔ)鏡像。避免安裝和配置那些無用的軟件包和SDK∧蓟眩現(xiàn)在有了 DISTROLESS DOCKER IMAGES 這樣的選擇扶关，可以被翻譯做 “非發(fā)行版的 Docker 鏡像”，它由 Google 開發(fā)近哟，并給每種語言運(yùn)行時(shí)都建立了?發(fā)行版無關(guān)的鏡像驮审，兼顧了安全性和大小兩方面。
在 Kubernetes 運(yùn)維方面吉执，這期的技術(shù)雷達(dá)新增了兩個(gè)工具疯淫。Kube-Bench 和 Heptio ARK。前者是大名鼎鼎的 K8S 機(jī)器學(xué)習(xí)社區(qū) Kubeflow 推出的一款基礎(chǔ)設(shè)施配置掃描工具戳玫，基于 K8S的 CIS 評(píng)分自動(dòng)檢查 Kubernetes 配置熙掺，涵蓋用戶身份驗(yàn)證，權(quán)限控制和數(shù)據(jù)安全等方面咕宿。后者是Kubernetes 跨云的解決方案廠商 Heptio 推出的一個(gè)集群和持久化卷的災(zāi)難恢復(fù)管理工具币绩。使用 Ark 可以顯著縮短基礎(chǔ)架構(gòu)發(fā)生故障時(shí)的恢復(fù)時(shí)間，還能輕松地將 Kubernetes 資源從一個(gè)集群遷移到另一個(gè)集群府阀，或者復(fù)制生產(chǎn)環(huán)境用于測試和排錯(cuò)缆镣。Ark支持主流的云存儲(chǔ)提供商(包括 AWS ，Azure 和 GoogleCloud )试浙，并且從版本0.6.0開始董瞻，提供了插件系統(tǒng)用于兼容其他備份與卷存儲(chǔ)平臺(tái)。雖然 GKE 等 Kubernetes 托管環(huán)境已經(jīng)提供了這類服務(wù)田巴，但如果需要自行運(yùn)維 Kubernetes 钠糊，不論是在本地還是云端，都請(qǐng)仔細(xì)考慮使用 Heptio Ark 進(jìn)行災(zāi)難恢復(fù)壹哺。
Rook 是一款運(yùn)行在Kubernetes集群中的開源云原生存儲(chǔ)編排工具仑撞，現(xiàn)在仍然在CNCF 進(jìn)行孵化溶其。與Ceph集成之后的Rook速勇，能將文件锚扎、塊和對(duì)象存儲(chǔ)系統(tǒng)引入到 Kubernetes 集群中，并能與使用這些存儲(chǔ)的其他應(yīng)用和服務(wù)一起無縫地運(yùn)行箩朴。通過使用一些 Kubernetes operator笛臣，Rook可以在控制層上編排Ceph，這樣就可以避免擠占應(yīng)用程序和Ceph之間的數(shù)據(jù)通道隧饼。
Kubernetes 一直是 無服務(wù)器架構(gòu)（Serverless Architecture）的理想平臺(tái)沈堡，圍繞著 Kubernetes 已經(jīng)有了很多 Serverless 解決方案，如 Kuberless 和 OpenFaaS燕雁。Knative 是 Google 推出的基于 Kubernetes Serverless 方案诞丽，你可以把它部署在任何 Kubernetes 集群上鲸拥。
Service Mesh 提供一致的發(fā)現(xiàn)、安全性僧免、跟蹤刑赶、監(jiān)控和故障處理，而無需共享API網(wǎng)關(guān)或ESB等設(shè)施懂衩。典型的實(shí)現(xiàn)是將每個(gè)服務(wù)進(jìn)程和輕量級(jí)反向代理以Side-Car 的方式一起部署撞叨，反向代理進(jìn)程可能在單獨(dú)的容器中。這些代理與服務(wù)注冊(cè)表浊洞，身份提供者牵敷，日志聚合器和其他服務(wù)進(jìn)行通信。服務(wù)互操作性和可觀測性是通過此代理的共享實(shí)現(xiàn)而不是共享運(yùn)行時(shí)實(shí)例獲得的法希。
隨著集中式的微服務(wù)網(wǎng)關(guān)和服務(wù)注冊(cè)/發(fā)現(xiàn)機(jī)制的逐漸臃腫枷餐，Service Mesh 會(huì)接起微服務(wù)規(guī)模化的接力棒苫亦。隨著 Linkerd 和 Istio 等開源項(xiàng)目將逐步成熟毛肋，這使得 service mesh 更容易實(shí)現(xiàn)。目前 Istio 仍遭受了來自性能方面的擔(dān)心屋剑，但我相信在某些場景下润匙，這些性能損耗是可以被復(fù)雜性平衡的。
Kubernetes 生態(tài)圈的發(fā)展一直圍繞著微服務(wù)進(jìn)行的唉匾。所以孕讳，結(jié)合微服務(wù)技術(shù)的發(fā)展更可以看清Kubernetes的發(fā)展軌跡。
微服務(wù)及其誤區(qū)
微服務(wù)的實(shí)踐正在渡過深水區(qū)肄鸽，判斷的依據(jù)很簡單：關(guān)于微服務(wù)的工具出現(xiàn)的越來越少卫病，而實(shí)踐和經(jīng)驗(yàn)越來越多油啤。這表明很多不會(huì)有很多新的通用問題需要解決典徘。事件風(fēng)暴(EVENT STORMING) 被放入了“采用”環(huán)中，這意味著事件風(fēng)暴將作為微服務(wù)實(shí)踐的核心技術(shù)之一益咬。事件風(fēng)暴是一項(xiàng)團(tuán)隊(duì)活動(dòng)逮诲，旨在通過領(lǐng)域事件識(shí)別出聚合根，進(jìn)而劃分微服務(wù)的限界上下文幽告。在活動(dòng)中梅鹦，團(tuán)隊(duì)先通過頭腦風(fēng)暴的形式羅列出領(lǐng)域中所有的領(lǐng)域事件，整合之后形成最終的領(lǐng)域事件集合冗锁，然后對(duì)于每一個(gè)事件齐唆，標(biāo)注出導(dǎo)致該事件的命令（Command），再然后為每個(gè)事件標(biāo)注出命令發(fā)起方的角色冻河，命令可以是用戶發(fā)起箍邮，也可以是第三方系統(tǒng)調(diào)用或者是定時(shí)器觸發(fā)等茉帅。最后對(duì)事件進(jìn)行分類整理出聚合根以及限界上下文。事件風(fēng)暴還有一個(gè)額外的好處是可以加深參與人員對(duì)領(lǐng)域的認(rèn)識(shí)锭弊。
在微服務(wù)的應(yīng)用中堪澎，分布式追蹤一直是一個(gè)困擾人們很久的問題。CNCF 的 Jaeger 的機(jī)制同樣來源于谷歌的 Dapper味滞，并遵循 OpenTracing 樱蛤。它在 Kubernetes 集群中安裝它也很簡單，它可以和Istio 配合使用剑鞍，在 Kubernetes 集群中與 Envoy集成進(jìn)行應(yīng)用程序追蹤昨凡。而 CNCF 所提供的工具漸漸會(huì)和 Spring Cloud 這種微服務(wù)全家桶的解決方案結(jié)合，變成未來微服務(wù)架構(gòu)的基準(zhǔn)參考模型攒暇。
除了 Java 社區(qū)以外土匀，其它語言的社區(qū)也躍躍欲試。例如這一期技術(shù)雷達(dá)介紹的 Ocelot形用，它是基于.NET Core實(shí)現(xiàn)的輕量級(jí)API網(wǎng)關(guān)項(xiàng)目就轧，它可以通過輕松的配置來實(shí)現(xiàn)路由轉(zhuǎn)發(fā)、請(qǐng)求聚合田度、服務(wù)發(fā)現(xiàn)妒御、認(rèn)證授權(quán)、限流熔斷镇饺、負(fù)載均衡等特性乎莉，它還集成了Service Fabric、Consul奸笤、Eureka等功能惋啃。目前 Ocelot 的功能已經(jīng)相當(dāng)完整，它在.NET Core社區(qū)的活躍度也很高监右。目測能夠作為未來 .NET 社區(qū)微服務(wù)實(shí)踐的首選边灭。
而在 Python 社區(qū)，出現(xiàn)了一個(gè)超輕量級(jí)的微服務(wù)框架 NameKo健盒，它也是 Flask的 替代方案绒瘦。與 Flask 不同的是 Nameko 只包含了 WebSocket、HTTP扣癣、AMQP 支持等有限功能惰帽。我非常喜歡這種簡單而輕量的框架，如果你采用 Python 作為微服務(wù)的實(shí)現(xiàn)語言父虑，你可以考慮考慮它该酗。
JavaScript 社區(qū)曾經(jīng)有一個(gè)從前端到后端“一統(tǒng)天下”的設(shè)想。也出現(xiàn)了 MEAN 這樣的全棧 Javascript框架∈亢浚現(xiàn)在 F# 社區(qū)出現(xiàn)了一個(gè)有力的競爭者：SAFE 呜魄。SAFE 技術(shù)棧是 Suave烁焙、Azure、Fable 和 Elmish 的簡稱耕赘。SAFE 囊括了一系列技術(shù)骄蝇，形成了前后端一致的 Web 開發(fā)技術(shù)棧。SAFE 在服務(wù)端和瀏覽器端都使用了 F# 語言操骡，因此注重于異步函數(shù)式類型安全的編程機(jī)制九火。它不僅提供了一些提高開發(fā)效率的功能比如熱加載; 還允許替換技術(shù)棧里的某些模塊，例如服務(wù)器端 Web 框架或云提供商册招。它很有希望成為微軟技術(shù)棧下 Serverless 微服務(wù)架構(gòu)的候選者岔激。
微服務(wù)的誤區(qū)
隨著微服務(wù)越來越火，很多組織開始盲目的追求微服務(wù)架構(gòu)是掰。但很多團(tuán)隊(duì)都把架構(gòu)通過把簡單的 API 進(jìn)行復(fù)雜的整合使架構(gòu)更加難以維護(hù)虑鼎。它用運(yùn)維復(fù)雜性換取了開發(fā)的復(fù)雜性。然而键痛，這需要堅(jiān)實(shí)的自動(dòng)化測試炫彩，持續(xù)交付和 DevOps 能力作為支撐。
這期技術(shù)雷達(dá)提出的分層式微服務(wù)架構(gòu)(LAYERED MICROSERVICES ARCHITECTURE)的組織是一種反模式絮短，他們?cè)谀承┓矫娲嬖谥黠@的矛盾江兢。這些組織都陷入了以技術(shù)角色為主來劃分服務(wù)的誤區(qū)，比如丁频，用戶體驗(yàn)API杉允、進(jìn)程 API 或系統(tǒng) API等。這樣會(huì)導(dǎo)致業(yè)務(wù)變更仍然會(huì)有緩慢而昂貴的多團(tuán)隊(duì)合作席里。
另外一點(diǎn)是叔磷，當(dāng)中臺(tái)戰(zhàn)略逐漸開始流行后，會(huì)導(dǎo)致前臺(tái)團(tuán)隊(duì)和后臺(tái)團(tuán)隊(duì)被從技術(shù)上分開奖磁，而缺乏了微服務(wù)所需要的整體業(yè)務(wù)能力改基。中臺(tái)更多強(qiáng)調(diào)的是內(nèi)部應(yīng)用的產(chǎn)品化和 SaaS 化能力。而不僅僅是割裂為獨(dú)立的微服務(wù)署穗。這樣寥裂，你需要額外的一個(gè)中間層來做前臺(tái)和中臺(tái)之間的轉(zhuǎn)換嵌洼。而這樣一個(gè)中間層案疲，無論是放到前臺(tái)和中臺(tái)都是不合理的。我仍然推薦圍繞業(yè)務(wù)能力組建一個(gè)端到端的微服務(wù)團(tuán)隊(duì)麻养。
由于微服務(wù)很多都支持基于事件的異步調(diào)用方式褐啡，這也影響到了前端用戶體驗(yàn)的設(shè)計(jì)。這就是在面向用戶的工作流中使用請(qǐng)求 — 響應(yīng)事件 (REQUEST-RESPONSE EVENTS IN USER-FACING WORKFLOWS)的系統(tǒng)設(shè)計(jì)鳖昌。這樣一來备畦，要么UI被阻塞低飒，要么用戶就必須等頁面收到響應(yīng)消息后重新加載。做出這類設(shè)計(jì)的主要依據(jù)往往是為了性能或是為了用統(tǒng)一的方式來處理后端之間的同步和異步通信懂盐。但這樣做會(huì)在開發(fā)褥赊、測試和運(yùn)維上所增加不必要的復(fù)雜度，遠(yuǎn)遠(yuǎn)超過了采用這種統(tǒng)一方式帶來的好處莉恼。所以拌喉，在用戶可接受的場景下，直接使用同步HTTP 請(qǐng)求來處理后端服務(wù)之間的同步通信俐银，而不必改成事件驅(qū)動(dòng)的設(shè)計(jì)尿背。如果設(shè)計(jì)的精妙，使用HTTP通信很少會(huì)成為分布式系統(tǒng)的瓶頸捶惜。
微服務(wù)架構(gòu)的一個(gè)顯著特征是系統(tǒng)組件和服務(wù)是圍繞業(yè)務(wù)能力進(jìn)行組織的田藐。無論系統(tǒng)規(guī)模大小，微服務(wù)都需要將系統(tǒng)功能和信息進(jìn)行有意義的分組和封裝吱七，以便拆分后的微服務(wù)能彼此獨(dú)立地交付業(yè)務(wù)價(jià)值汽久。微服務(wù)是從業(yè)務(wù)角度對(duì)架構(gòu)的重新審視，而以前的服務(wù)架構(gòu)方式會(huì)從技術(shù)角度組織服務(wù)踊餐。
安全
技術(shù)雷達(dá)從來沒有像這一期有這么多的安全相關(guān)的內(nèi)容回窘。今年的信息安全事件頻發(fā)，并和技術(shù)的發(fā)展結(jié)合在一起市袖，往往給人們一種“新技術(shù)一定會(huì)帶來安全問題”的錯(cuò)覺啡直。而安全的主要因素是人，工具只是降低工作量和節(jié)省工作時(shí)間的一種方式苍碟，它不能替代安全設(shè)計(jì)和安全活動(dòng)本身酒觅。我把安全單獨(dú)列為一節(jié)主要是為了能夠使您對(duì)安全實(shí)踐有一個(gè)端到端的認(rèn)識(shí)。
運(yùn)維相關(guān)的安全實(shí)踐和工具
對(duì)敏感數(shù)據(jù)保持適當(dāng)?shù)目刂剖窍喈?dāng)困難的微峰，尤其是在出于對(duì)數(shù)據(jù)備份和恢復(fù)的目的而將數(shù)據(jù)復(fù)制到主數(shù)據(jù)系統(tǒng)之外的時(shí)候舷丹。密鑰粉碎(CRYPTO SHREDDING)是通過故意覆蓋或刪除用于保護(hù)該數(shù)據(jù)的加密密鑰來使敏感數(shù)據(jù)無法讀取的做法。例如蜓肆，可以使用隨機(jī)密鑰對(duì)數(shù)據(jù)庫中客戶個(gè)人詳細(xì)信息表的所有記錄進(jìn)行一對(duì)一加密颜凯，然后使用另一張表來存儲(chǔ)密鑰。如果客戶行使了“被遺忘的權(quán)利”仗扬，您可以簡單地刪除相應(yīng)的密鑰症概，從而有效地“粉碎”加密數(shù)據(jù)。當(dāng)你有信心對(duì)小規(guī)模加密密鑰集合維持適當(dāng)控制早芭，但對(duì)較大數(shù)據(jù)集的控制信心不足時(shí)彼城，此項(xiàng)技術(shù)非常有效。
在云計(jì)算平臺(tái)上維護(hù)基礎(chǔ)設(shè)施首要的工作就是設(shè)立一個(gè)安全的框架，其次需要實(shí)踐和工具來進(jìn)行安全檢查募壕。
繼混沌工程（Chaos Engineering）之后调炬，安全混沌工程(Security Chaos Engineering) 也發(fā)展的越來越好，使用此技術(shù)的團(tuán)隊(duì)確信他們的安全策略足以應(yīng)對(duì)常見的安全故障模式舱馅。不過缰泡，這方面的實(shí)踐僅有 ChaoSlingr一個(gè)工具，且僅支持 AWS 平臺(tái)代嗤。就像之前提到的 Chaos Engineering Katas匀谣，我相信未來會(huì)有 Security Chaos Engineering Katas 作為日常安全的練習(xí)。
隨著云計(jì)算平臺(tái)基礎(chǔ)設(shè)施即代碼的復(fù)雜度提升资溃，相應(yīng)的安全掃描工具也應(yīng)運(yùn)而生武翎。Watchmen是個(gè)采用 Python 編寫的工具，它為由交付團(tuán)隊(duì)自主擁有和運(yùn)營 AWS 賬戶配置提供基于規(guī)則驅(qū)動(dòng)的掃描溶锭。技術(shù)雷達(dá)所提到的 Scout2 已經(jīng)不再維護(hù)宝恶，它被遷移到了ScoutSuite，目前支持 AWS趴捅，但即將包括 Azure 和 Google Cloud Platform垫毙。我強(qiáng)烈建議你將這些工具集成到你的基礎(chǔ)設(shè)施流水線（Pipeline for Infrastructure）里。
開發(fā)相關(guān)的安全實(shí)踐和工具
我們已經(jīng)經(jīng)歷了一些把密碼存儲(chǔ)到代碼庫上導(dǎo)致的數(shù)據(jù)泄露實(shí)踐拱绑。將安全憑據(jù)或其他機(jī)密提交到源代碼倉庫是一個(gè)主要的攻擊向量综芥。GIT-SECRETS 是防止將密碼或其他敏感信息提交到 git 倉庫的小工具。AWS 實(shí)驗(yàn)室也提供了一個(gè)同名的工具猎拨，git-secrets 內(nèi)建支持常見的 AWS 密鑰和憑據(jù)膀藐，也可以為其他的提供商進(jìn)行快速配置。
SNYK是一個(gè)可以查找红省、修復(fù)及監(jiān)控 npm 额各、Ruby 、Python 吧恃、Scala 虾啦、Golang 、.NET 痕寓、PHP 傲醉、Java 與 Docker 依賴樹中漏洞的平臺(tái)。將 Snyk 加入構(gòu)建流水線后呻率，它會(huì)基于一個(gè)托管的漏洞數(shù)據(jù)庫硬毕，持續(xù)地監(jiān)控和測試你的庫依賴樹。在發(fā)現(xiàn)漏洞時(shí)筷凤，還可以給出可以解決該安全問題的最小的依賴版本昭殉。目前它支持多種 Git 倉庫服務(wù)和 PaaS 平臺(tái)服務(wù)。
如果你想對(duì) Web 應(yīng)用進(jìn)行安全掃描藐守，你可以采用 Archery挪丢，它是一個(gè)開源的安全工具，并正在將其與其他工具(包括 Zap )相結(jié)合卢厂，輕松地將安全工具集成到構(gòu)建與部署系統(tǒng)中乾蓬。你也可以通過 Archery 的工作面板，跟蹤漏洞及應(yīng)用程序和網(wǎng)絡(luò)的安全掃描結(jié)果慎恒。
同樣任内，隨著微服務(wù)的流行，它的安全問題也被提升到了最高的高度融柬。SPIFFE (Secure Production Identity Framework For Everyone死嗦， 適用于所有人的安全生產(chǎn)身份框架) 以特制X.509證書的形式為現(xiàn)代生產(chǎn)環(huán)境中的每個(gè)工作負(fù)載提供安全標(biāo)識(shí)。 SPIFFE消除了對(duì)應(yīng)用程序級(jí)身份驗(yàn)證和復(fù)雜網(wǎng)絡(luò)級(jí)ACL配置的需求粒氧，Istio 默認(rèn)就采用了 SPIFFE越除。
參考
https://www.thoughtworks.com/cn/radar/
https://cloudplatformonline.com/2018-state-of-devops.html
https://puppet.com/resources/whitepaper/state-of-devops-report
我是顧宇，是一名在埃森哲工作的職業(yè)咨詢師外盯。我目前專注于產(chǎn)品服務(wù)設(shè)計(jì)摘盆、敏捷軟件開發(fā)、DevOps 饱苟、云計(jì)算以及應(yīng)用架構(gòu)領(lǐng)域的技術(shù)和實(shí)踐落地孩擂。熱愛閱讀、寫作箱熬、旅行和健身类垦。具有強(qiáng)大的好奇心的經(jīng)濟(jì)學(xué)和腦科學(xué)愛好者，喜歡結(jié)交不同領(lǐng)域的朋友城须，一起體驗(yàn)并分享世界上未知的美好护锤。
歡迎關(guān)注我的公眾號(hào)：顧宇的研習(xí)筆記
本作品采用知識(shí)共享署名-禁止演繹 4.0 國際許可協(xié)議進(jìn)行許可
