3月25日，網易雲技術布道系列第三期•對話架構師活動在網易杭州園區舉辦，網易雲基礎服務總經理陳諤、美麗聯合集團研發部副總裁曾憲傑和51信用卡cto郭威分別從雲原生應用技術、技術人員的成長和技術對業務的價值等方面帶來了乾貨分享。本文將為大家重點解讀網易雲基礎服務總經理陳諤帶來的分享：cloud native 實踐從0到1。
陳諤，網易雲基礎服務總經理，現負責網易雲計算平台產品線建設，對內主導公司軟體基礎設施雲化改造，建設網易私有雲將網易網際網路產品線遷入私有雲環境，對外打造公有雲產品，實踐網易雲計算戰略。對分布式系統設計開發、雲計算平台系統架構有一定的經驗和理解。個人同時致力於提公升尋求解決方案幫助開發人員提公升開發效率，近年來一直帶領團隊推進公司開發技術棧的標準化、工具化。
說到cloud native，國內大多數都翻譯成雲原生，就是讓雲成為成功的基石，而不是障礙。陳諤對於為什麼要實現雲原生應用深有體會，網易從2023年開始實施雲化的戰略，當第一版雲計算平台建好的時候，開始引導公司的專案逐漸向雲遷移。這個過程中就遇到了乙個問題：用上雲之後，並沒有變得效率奇高，甚至有些專案的效率反而有所下降，大家有很多抱怨。
從那個時候陳諤就有乙個想法，雲計算怎樣才能成為公司和開發團隊成功的基石，而不是用上雲之後給你製造麻煩。陳諤認為要做到這一點首先要理解雲的優勢，規避雲的弱點；另一方面要充分利用雲的各層能力，幫助你去成功。所以雲原生就是採用適合雲端的軟體架構和研發模式去做這個事情。
關於如何實踐雲原生，陳諤為大家分享了一些建議。假設大家不是類似bat這樣規模的公司，或者有非常強大的it團隊，當擇技術路線的時候，陳諤建議大家使用公有雲，為什麼呢？
彈性首先，使用公有雲起步的成本非常低，不需要你去租機房、買物理機，每個月幾百塊錢就可以起步了。如果你成功了，在爆發性增長的時候，公有雲有足夠大的資源彈性來幫助你從一台scale到幾百台，不需要臨時去買伺服器。
網路質量
另一方面，由於公有雲的規模化效應，網路質量是自建不可比擬的：
managed cloud service
雲計算有資料庫、中介軟體這些服務，並且不需要你去關注高可用部署、故障恢復、擴縮容等系統層面的運維，作業系統核心級掌控、中介軟體原始碼級維護也均由雲提供商負責，並且有明確的sla保障。
高可用保障
另外，雲計算可以幫你做高階別的高可用保障。日常的高可用保障，比如雙機熱備也好，冷備也好，都比不過公有雲提供的多可用區的保障。雲的多可用區至少是idc級別的，在乙個可用區內就像一張大網一樣，至少保證三層的連線，保證你的業務都是互通的，整體架構不用考慮跨機房的問題。
雲還有多region的保障，有一些公司會做異地多活的架構，當然這對業務的侵入性是很大的，但至少可以用多region的設施，來做資料的災備。
另外，雲的進化速度很快，會持續地更新，現在大多數都是基於linux的技術棧，可能會不時地出現bug或安全漏洞，如果自己去跟進是非常困難的，公有雲一般都會有專業的團隊，及時跟進和修復這些安全問題，又省下了使用者一筆人員開銷。
公有雲的取捨
當然，公有雲要支援這麼大規模的使用者，本身有一定的取捨
design for failure：公有雲傾向於更快失敗（影響範圍受控）、更快恢復。如果你用的是物理機，出現問題的時候你會關注這個物理機是不是還「活著」。而公有雲如果發現一台機器掛了，會直接進行服務遷移和重啟，因為公有雲本身有sla的承諾，為了保證系統的魯棒性，會更快地把這些疑似故障的節點排除掉。
由於公有雲這樣的特性，日常業務必須結合公有雲能力實施高可用架構：
design for scale：虛擬化效能稍弱於物理機，公有雲更追求交付的效能指標的穩定，避免租戶業務間的影響，支援業務做scale。對於開發者來說：
專案工程化
除了上面提到的基礎設施，在專案的工程化方面，陳諤也為大家帶來了一些啟示。陳諤認為專案工程化是研發協作與雲端運維的基礎，也是很多團隊在起步的時候可能會忽視的事情。專案的整個流程中，開發、測試、發布的每一步都涉及到公司內角色之間的協作，如果這些步驟做得不流暢，每乙個環節的銜接非常困難，效率就會變的非常低，所以專案工程化是對高效構建、發布、執行流程的支援。
合理的版本控制工具
那麼如何做到專案的工程化呢？首先要選擇合理的版本控制工具與策略：
常見的版本控制策略包括：
基於配置的依賴管理
然後可以去做基於配置的依賴管理：
接下來要合理拆分模組，可以按業務拆分模組，同時實現公共**的模組化。
使用docker實現環境一致性
之前在網易，對穩定性要求很高的產品，其發布流程通常都很曲折，主要原因在於環境的不一致。陳諤的建議是使用docker實現環境的一致性，docker容器完整虛擬化了linux作業系統，將業務**與執行環境裝箱為docker容器發布到生產環境，差異僅僅為外部注入的配置（如資料庫位址等），容器內部檔案在開發環境一旦發布則不再變化，從而保證開發環境與生產環境一致。
工程化是做業務架構，建立乙個高效團隊的基礎，接下來要考慮的就是服務化的思維。微服務是當下很流行的概念，採用微服務確實能為應用的迭代和架構帶來很多好處。但服務化的架構會帶來額外的負擔，如果乙個專案還處在初期階段，網易雲的建議則是服務化思維先於服務化架構。
雖然業務初期，不適合服務化，但是應該為後續的服務化做一些準備，否則後面想拆分的時候會變得非常困難：
隨著業務的壯大，是否要採用微服務，就要去衡量微服務帶來的收益是否大於成本？
收益成本
降低實施成本利用基於kubernetes的基礎設施可以簡化微服務，一方面kubernetes提供了基於網域名稱的服務發現
kubernetes還可以做基於 iptables的透明rpc 分發
比如，服務 a 訪問服務 b 的 虛擬ip vip，利用 iptables 做 dnat，轉成b中的所有成員，服務a可以直接，並利用 probability特性按權重分發請求，比網域名稱做輪轉的負載均衡效果要好，因為iptables可控，網域名稱不可控。
用kubernetes還可以讓你獲得自動化運維能力
kubernetes 以解耦的基礎服務層的方式提供了對服務化的支援，避免了**實現層面的耦合，通過雲端託管 kubernetes 服務能夠將實現服務化的成本大幅降低。而且kubernetes對業務沒有侵入性，實現服務化的代價相對會比較小，後面業務變得非常重，需要細粒度控制的時候，再用到其它框架也沒有什麼影響。
網易雲深度整合了docker技術和kubernetes集群編排技術，網易雲中會有乙個kubernetes master，所有租戶的業務都可以使用這個master，不用使用者自己維護。
前面講到的都是雲原生相關的技術，實際上實現雲原生還需要一些研發、運維和組織架構上的方式調整，比如devops。devops的出現是為了解決運維角色與開發角色的矛盾，運維追求的是可用率優先，而開發希望應用能快速更新迭代。
devops 與微服務
微服務架構能夠支援更高頻的迭代，降低更新迭代的風險，這與 devops 的目標是一致；但是微服務架構也會給運維帶來成倍的工作量，可基於devops分散運維操作，而不是集中依賴少量運維角色。
實施devops
實施devops需要ci/cd、編排、故障診斷等工具鏈的支援，同時需要運維實現從操作到審計的職能轉換，運維工作前置，在前期和開發團隊合作。很多運維還需要開發工具，提高運轉效率。
jenkins-容器-映象倉庫-服務編排
pipeline as code：實施服務化後持續整合的複雜度成倍增加，需要定義大量的流程，包含大量jobs，以**的方式管理pipeline能夠支援審計，有效管理複雜性並降低維護成本
日誌服務-分布式跟蹤系統-效能管理服務
最後，陳諤將雲原生架構實現的要點總結如下，希望能給雲計算的使用者帶來有價值的參考：
讀書1 從0到1
總結你身邊是不是總有這樣的人，他特立獨行，有的時候厭煩規則，顯得與眾不同。如果有，請盯住他們，本書就以這類人為論述，作者對他們的迷戀堪稱瘋狂。最近看的一場電影 綠皮書 其中的唐雪莉和托尼就是這樣的人，托尼改掉歧視黑人的行為，甚至為黑人唐打工，而唐也與其他黑人格格不入，他特立獨行，不了解黑人 他是鋼琴...
需求從0到1
軟體是一種工具，是用來輔助人們解決某些問題的 相關的問題，組成問題領域 因此解決問題是軟體存在的價值，所以軟體的價值是符合某個問題領域的需求，從問題領域出發找構建軟體系統的重要性由此而得。充分了解問題領域，能夠幫助你理解需求 涉眾分析報告 通過以上大類，對專案範圍的社眾進行調查和訪談，書寫成涉眾報告...
《從0到1》雜感
從0到1 最近非常火，到處都在談論這本書。書中討論了很多問題，幾乎涵蓋了乙個初創企業要面對的方方面面。個人印象最深刻的，是書中對 壟斷企業 的描述。彼得.蒂爾給出了壟斷企業的四大特徵 專利技術 網路效應 規模經濟 品牌優勢。專利技術。專利技術是公司的核心優勢，很難被其他公司抄襲，最好領先行業平均水平...