云原生
云時(shí)代的基礎(chǔ)設(shè)施介紹
什么是云基礎(chǔ)設(shè)施
我理解的基礎(chǔ)設(shè)施脯燃，不只是服務(wù)器管理汤求；是各種云（AWS，阿里云仇轻，騰訊云等）背后的或者說業(yè)務(wù)層面以下的各種技術(shù)和服務(wù)。
服務(wù)化
專業(yè)化
擴(kuò)展性
基礎(chǔ)設(shè)施領(lǐng)域是個(gè)高度開源和技術(shù)主導(dǎo)的領(lǐng)域奶甘；基礎(chǔ)設(shè)施越強(qiáng)大篷店，業(yè)務(wù)的擴(kuò)展性和靈活性越強(qiáng)。越能跳出資源的限制臭家，業(yè)務(wù)越能從摘取低垂果實(shí)去攀登更高的業(yè)務(wù)價(jià)值疲陕。基礎(chǔ)設(shè)施領(lǐng)域任何創(chuàng)新可能會(huì)帶來業(yè)務(wù)層的蝴蝶效應(yīng)钉赁。
-
資源云化
資源集中蹄殃，規(guī)模化共享你踩；想象下業(yè)務(wù)程序一般是白天比較繁忙诅岩，大數(shù)據(jù)離線計(jì)算一般是晚上才大批量運(yùn)行的讳苦；這些資源在時(shí)間上錯(cuò)開的，就意味著同一批物理資源是可以共享的吩谦。
-
業(yè)務(wù)云化
云之前一般是業(yè)務(wù)去適配或者操作資源鸳谜，云時(shí)代是資源來服務(wù)業(yè)務(wù)。
三駕馬車
微服務(wù)
容器 / k8s
DevOps
問題來了式廷，
這三者如何表達(dá)業(yè)務(wù)對(duì)基礎(chǔ)設(shè)施的需求咐扭？
先上哪個(gè)呢？如何上懒棉？
還是全部上草描？
木桶效應(yīng)？反木桶效應(yīng)策严？
微服務(wù)
從業(yè)務(wù)角度來穗慕，DDD領(lǐng)域驅(qū)動(dòng)等；這方面技術(shù)中心非常厲害妻导。
從資源和底層技術(shù)角度來說逛绵，微服務(wù)比傳統(tǒng)SOA或者單體應(yīng)用有著明顯的區(qū)別。
傳統(tǒng)業(yè)務(wù)一般只有幾個(gè)模塊倔韭，每個(gè)模塊功能復(fù)雜术浪，邏輯全在同一個(gè)進(jìn)程內(nèi)解決。所以微服務(wù)的維護(hù)場(chǎng)景主要側(cè)重于單點(diǎn)問題寿酌、負(fù)載均衡胰苏、資源擴(kuò)容、單個(gè)進(jìn)程狀態(tài)維護(hù)等醇疼；像呵護(hù)寶寶一樣呵護(hù)業(yè)務(wù)進(jìn)程硕并。
一個(gè)系統(tǒng)下，可能會(huì)有幾百個(gè)微服務(wù)秧荆，這么多的微服務(wù)是不可能一個(gè)個(gè)精心養(yǎng)護(hù)的倔毙；所以管理這些微服務(wù)一定就會(huì)有規(guī)范和流程；然后根據(jù)角色進(jìn)行關(guān)注點(diǎn)分離設(shè)計(jì)乙濒。
運(yùn)維陕赃、平臺(tái)角度
跨環(huán)境部署運(yùn)維
服務(wù)監(jiān)控告警
服務(wù)治理
集中化配置管理
集中化日志管理
微服務(wù)接口規(guī)范
詳細(xì)調(diào)用鏈跟蹤排障
開發(fā)者角度
代碼復(fù)用率高
需求快速響應(yīng)
性能快速提升
數(shù)據(jù)統(tǒng)一性提升
數(shù)據(jù)訪問能力提升
數(shù)據(jù)存儲(chǔ)依賴性降低
資源利用率提升
舉例：?jiǎn)蝹€(gè)微服務(wù)一般是無狀態(tài)的，有狀態(tài)的部分應(yīng)該被抽離到中間件或者消息隊(duì)列里面颁股。這樣微服務(wù)就具備水平擴(kuò)展能力么库。
每個(gè)進(jìn)程（微服務(wù)）的狀態(tài)如何被暴露，被周知豌蟋，被告警之后廊散，實(shí)現(xiàn)該進(jìn)程（服務(wù)）的自動(dòng)化管理。
每個(gè)進(jìn)程的metadata（元信息）的管理梧疲；啟動(dòng)命令允睹、運(yùn)行IP、服務(wù)名幌氮、關(guān)聯(lián)數(shù)據(jù)庫缭受、關(guān)聯(lián)redis、cpu和memory配置该互、狀態(tài)獲取方式等等米者。
容器 / k8s
k8s被稱為云操作系統(tǒng)，是基礎(chǔ)設(shè)施的基礎(chǔ)宇智。
容器是什么蔓搞，最核心的本質(zhì)對(duì)資源進(jìn)行抽象；然后業(yè)務(wù)聲明式表達(dá)資源需求進(jìn)行匹配随橘。通常情況下喂分，k8s是業(yè)界當(dāng)前對(duì)資源利用率的最優(yōu)解。
k8s要完成對(duì)runtime（服務(wù)運(yùn)行時(shí)）的管理机蔗。生命周期的管理蒲祈，圍繞生命周期的計(jì)算、存儲(chǔ)萝嘁、網(wǎng)絡(luò)梆掸，對(duì)三者進(jìn)行抽象和調(diào)度，實(shí)現(xiàn)自動(dòng)化管理牙言，并對(duì)相關(guān)狀態(tài)酸钦、指標(biāo)進(jìn)行暴露。
我之前所在的PingCAP是家技術(shù)公司（開源分布式數(shù)據(jù)庫）咱枉；公司核心產(chǎn)品TiDB數(shù)據(jù)庫是開源的卑硫。最初公司想圍繞著基礎(chǔ)設(shè)施做個(gè)閉源的商業(yè)化管理平臺(tái)；花費(fèi)將近半年時(shí)間的技術(shù)開發(fā)庞钢；平臺(tái)越做越像k8s拔恰，最后廢棄這個(gè)項(xiàng)目，開發(fā)能力轉(zhuǎn)向k8s基括。一家初創(chuàng)公司颜懊，花費(fèi)大量人力嘗試后轉(zhuǎn)向k8s；到現(xiàn)在k8s開發(fā)維持著個(gè)龐大團(tuán)隊(duì)风皿。
DevOps
說起DevOps河爹，必須要放出下圖；資源桐款、業(yè)務(wù)和管理三者之間的橋梁咸这。要準(zhǔn)確的表達(dá)出這三者的關(guān)系，意味著就是公司組織架構(gòu)和管理形態(tài)映射到DevOps系統(tǒng)里面魔眨。
“如果團(tuán)隊(duì)媳维、部門酿雪、子部門等的組織結(jié)構(gòu)沒有緊密反映產(chǎn)品的必要組成或產(chǎn)品組成的關(guān)系，那么項(xiàng)目將會(huì)遇到麻煩侄刽。因此指黎，應(yīng)該確保組織結(jié)構(gòu)兼容于產(chǎn)品架構(gòu)≈莸ぃ”——《敏捷軟件開發(fā)的組織模式》
效率和管理的平衡
DevOps不只是一個(gè)管理系統(tǒng)醋安，也是個(gè)效率系統(tǒng)；
DevOps是以效率前提將各種邏輯（管理邏輯墓毒，組織架構(gòu)形態(tài)）顯性或隱性嵌入到系統(tǒng)中吓揪；然后制定流程規(guī)范和工具自動(dòng)化。這是我認(rèn)為DevOps核心關(guān)鍵點(diǎn)所计。
流程梳理清楚
通過工具把梳理的流程自動(dòng)化
消息的Hub柠辞，交互點(diǎn)
DevOps有Pipeline（流程）的存在，就意味著一定是信息的交互點(diǎn)醉箕，各種信息上下文的交換钾腺。
信息一般分為兩類；metadata信息和狀態(tài)信息
metadata信息（元信息）讥裤；要準(zhǔn)確的描述清楚服務(wù)和服務(wù)的屬性放棒；服務(wù)的所屬系統(tǒng)、服務(wù)啟動(dòng)命令己英、數(shù)據(jù)庫地址间螟、中間件地址和參數(shù)、依賴的上下游损肛、所運(yùn)行的IP列表厢破、服務(wù)狀態(tài)獲取方式等。這個(gè)信息一般是記錄在CMDB里面治拿，提供API接口給上下游消費(fèi)摩泪。
狀態(tài)信息；基于時(shí)間維度表達(dá)服務(wù)的狀態(tài)信息劫谅，服務(wù)的啟停時(shí)間见坑、是否健康、監(jiān)控?cái)?shù)據(jù)捏检、日志關(guān)鍵字等荞驴。
如何讓信息流動(dòng)起來
信息收集之后不用起來是沒有意義的，如何讓信息流轉(zhuǎn)起來贯城，表達(dá)出用戶和業(yè)務(wù)需求熊楼？
參考GitHub上開源項(xiàng)目，一個(gè)優(yōu)秀的開源項(xiàng)目能犯，來自全世界的人員開發(fā)和維護(hù)鲫骗；不同的文化背景犬耻，不同的技術(shù)層次，不同的目標(biāo)價(jià)值挎峦；在同一個(gè)項(xiàng)目里面修改代碼香追，并且修改后的代碼全世界在使用合瓢，是如何做到的信息傳達(dá)坦胶？
云原生
不管基礎(chǔ)架構(gòu)如何變遷，應(yīng)用架構(gòu)總是存在晴楔，好的應(yīng)用架構(gòu)應(yīng)該是能適應(yīng)乃至充分利用基礎(chǔ)設(shè)施的變化顿苇，才能保持它的活力和技術(shù)競(jìng)爭(zhēng)力。對(duì)于云原生也是相似的税弃，如果沒有利用好云的特性纪岁，在今天各行業(yè)客戶都要拓展更廣闊市場(chǎng)的前提下，大家都想要異地多活则果、全球部署的能力幔翰，如果還是用老的 IDC 思路去設(shè)計(jì)應(yīng)用架構(gòu)，很難西壮。
面向云原生的應(yīng)用架構(gòu)遗增，從某種意義上說，為了獲得了更大計(jì)算資源款青、彈性伸縮做修、自動(dòng)智能化的可能性，必然會(huì)對(duì)業(yè)務(wù)有前置條件和要求抡草。最簡(jiǎn)單的例子就是 dockerfile饰及，一個(gè)標(biāo)準(zhǔn)化的文件可以讓軟件瞬間分發(fā)到幾千臺(tái)服務(wù)器，但寫過的人都知道康震，你必須非沉呛克制和準(zhǔn)確地表達(dá)清晰你的需求，不能像過去一樣腿短，基于中心化的基礎(chǔ)設(shè)施屏箍，配置滿天飛。所以業(yè)界對(duì)于面向云原生的軟件交付有了"不可變基礎(chǔ)設(shè)施"這個(gè)核心原則答姥，也是現(xiàn)在云原生平臺(tái)或者系統(tǒng)交付時(shí)最核心的理念之一铣除。
必須要提一下CNCF（云原生基金會(huì)），我們提的云原生概論是這個(gè)組織倡導(dǎo)的鹦付；我們用的幾乎所有云原生工具或者軟件都是在這個(gè)組織下孵化尚粘、成長(zhǎng)起來，然后改變業(yè)界的敲长。
CNCF Cloud Native Interactive Landscape
目標(biāo)是什么
當(dāng)三駕馬車成熟時(shí)郎嫁，我們已經(jīng)踏入云原生的大門秉继。但是我們一定要明確，我們希望云原生給我們解決什么泽铛？
在云原生領(lǐng)域的Serviceless和Service Mesh是用來解決什么痛點(diǎn)尚辑、處理什么場(chǎng)景。
Services Mesh盔腔，即服務(wù)網(wǎng)格杠茬；通過在容器內(nèi)添加一個(gè)代理容器，把業(yè)務(wù)的網(wǎng)絡(luò)調(diào)用從代碼里面抽離出來弛随，通過基礎(chǔ)設(shè)施來完成瓢喉。這個(gè)代理容器即可以看做基礎(chǔ)設(shè)施，也可以看做框架舀透。
Serviceless栓票，即無服務(wù)架構(gòu)；云函數(shù)（FaaS)等愕够；業(yè)務(wù)的邏輯函數(shù)和框架分離走贪，框架和基礎(chǔ)設(shè)施融合；用戶的請(qǐng)求先到框架層惑芭，框架統(tǒng)一來路由坠狡，分配資源。
從“云化”到“云原生化”的這個(gè)過程强衡，是企業(yè)數(shù)字化轉(zhuǎn)型深入過程擦秽，需要解決傳統(tǒng)應(yīng)用單體架構(gòu)厚重、煙囪式架構(gòu)等帶來的一系列應(yīng)用層面的問題漩勤，云對(duì)業(yè)務(wù)的價(jià)值不能僅停留在資源供給的階段感挥。
而是需要讓業(yè)務(wù)能力生于云、長(zhǎng)于云越败，同時(shí)基于云構(gòu)建的新生能力與既有能力有機(jī)協(xié)同触幼。生于云是指基于云原生的技術(shù)、架構(gòu)和服務(wù)來構(gòu)建企業(yè)應(yīng)用究飞，長(zhǎng)于云是指充分利用云的優(yōu)勢(shì)來助力企業(yè)應(yīng)用和業(yè)務(wù)發(fā)展置谦，是數(shù)字化建設(shè)、業(yè)務(wù)智能升級(jí)的基石亿傅。
