服務化原則
在軟體開發過程中，當代碼數量與開發團隊規模都擴張到一定程度後，就需要重構應用，通過子產品化與元件化的手段分離關注點，降低應用的複雜度，提升軟體的開發效率，降低維護成本。
如圖 1，随着業務的不斷發展，單體應用能夠承載的容量将逐漸到達上限，即使通過應用改造來突破垂直擴充（Scale Up）的瓶頸，并将其轉化為支撐水準擴充（Scale Out）的能力，在全局并發通路的情況下，也依然會面臨資料計算複雜度和存儲容量的問題。
是以，需要将單體應用進一步拆分，按業務邊界重新劃分成分布式應用，使應用與應用之間不再直接共享資料，而是通過約定好的契約進行通信，以提高擴充性。
服務化設計原則是指通過服務化架構拆分不同生命周期的業務單元，實作業務單元的獨立疊代，進而加快整體的疊代速度，保證疊代的穩定性。同時，服務化架構采用的是面向接口程式設計方式，增加了軟體的複用程度，增強了水準擴充的能力。服務化設計原則還強調在架構層面抽象化業務子產品之間的關系，進而幫助業務子產品實作基于服務流量（而非網絡流量）的政策控制和治理，而無須關注這些服務是基于何種程式設計語言開發的。
有關服務化設計原則的實踐在業界已有很多成功案例。其中影響最廣、最為業界稱道的是 Netflix 在生産系統上所進行的大規模微服務化實踐。通過這次實踐，Netflix 在全球不僅承接了多達 1.67 億訂閱使用者以及全球網際網路帶寬容量 15% 以上的流量，而且在開源領域貢獻了 Eureka、Zuul、Hystrix 等出色的微服務元件。
不僅海外公司正在不斷進行服務化實踐，國内公司對服務化也有很高的認知。随着近幾年網際網路化的發展，無論是新銳網際網路公司，還是傳統大型企業，在服務化實踐上都有很好的實踐和成功案例。阿裡巴巴的服務化實踐發端于 2008 年的五彩石項目，曆經 10 年的發展，穩定支撐曆年大促活動。以 2019 年“雙 11”當天資料為例，阿裡巴巴的分布式系統創單峰值為每秒 54.4 萬筆，實時計算處理為每秒 25.5 億筆。阿裡巴巴在服務化領域的實踐，已認證 Apache Dubbo、Nacos、Sentinel、Seata、Chaos Blade 等開源項目分享給業界， 同時，這些元件與 Spring Cloud的內建 Spring Cloud Alibaba 已成為 Spring Cloud Netflix 的繼任者。
雖然随着雲原生浪潮的興起，服務化原則不斷演進、落地于實際業務，但企業在實際落地過程中也會遇到不少的挑戰。比如，與自建資料中心相比，公有雲下的服務化可能存在巨大的資源池，使得機器錯誤率顯著提高；按需付費增加了擴縮容的操作頻度；新的環境要求應用啟動更快、應用與應用之間無強依賴關系、應用能夠在不同規格的節點之間随意排程等諸多需要考慮的實際問題。但可以預見的是，這些問題會随着雲原生架構的不斷演進而得到逐一解決。
彈性原則
彈性原則是指系統部署規模可以随着業務量變化自動調整大小，而無須根據事先的容量規劃準備固定的硬體和軟體資源。優秀的彈性能力不僅能夠改變企業的 IT 成本模式，使得企業不用再考慮額外的軟硬體資源成本支出（閑置成本），也能更好地支援業務規模的爆發式擴張，不再因為軟硬體資源儲備不足而留下遺憾。
在雲原生時代，企業建構 IT 系統的門檻大幅降低，這極大地提升了企業将業務規劃落地為産品與服務的效率。這一點在移動網際網路和遊戲行業中顯得尤為突出。一款應用成為爆款後，其使用者數量呈現指數級增長的案例不在少數。而業務呈指數級增長會對企業 IT 系統的性能帶來巨大考驗。面對這樣的挑戰，在傳統架構中，通常是開發人員、運維人員疲于調優系統性能，但是，即使他們使出渾身解數，也未必能夠完全解決系統的瓶頸問題， 最終因系統無法應對不斷湧入的海量使用者而造成應用癱瘓。
除了面臨業務呈指數級增長的考驗之外，業務的峰值特征将是另一個重要的挑戰。比如，電影票訂票系統下午時段的流量遠超淩晨時段，而周末的流量相比工作日甚至會翻好幾倍；還有外賣訂餐系統，在午餐和晚餐前後往往會出現訂單峰值時段。在傳統架構中，為了應對這類具有明顯峰值特征的場景，企業需要為峰值時段的流量提前準備大量的計算、存儲及網絡資源并為這些資源付費，而這些資源在大部分時間内卻處于閑置狀态。
是以，在雲原生時代，企業在建構 IT系統時，應該盡早考慮讓應用架構具備彈性能力，以便在快速發展的業務規模面前靈活應對各種場景需求，充分利用雲原生技術及成本優勢。
要想建構彈性的系統架構，需要遵循如下四個基本原則。
- 按功能切割應用
一個大型的複雜系統可能由成百上千個服務組成，架構師在設計架構時，需要遵循的原則是：将相關的邏輯放到一起，不相關的邏輯拆解到獨立的服務中，各服務之間通過标準的服務發現（Service Discovery）找到對方，并使用标準的接口進行通信。各服務之間松耦合，這使得每一個服務能夠各自獨立地完成彈性伸縮，進而避免服務上下遊關聯故障的發生。
- 支援水準切分
按功能切割應用并沒有完全解決彈性的問題。一個應用被拆解為衆多服務後，随着使用者流量的增長，單個服務最終也會遇到系統瓶頸。是以在設計上，每個服務都需要具備可水準切分的能力，以便将服務切分為不同的邏輯單元，由每個單元處理一部分使用者流量，進而使服務自身具備良好的擴充能力。這其中最大的挑戰在于資料庫系統，因為資料庫系統自身是有狀态的，是以合理地切分資料并提供正确的事務機制将是一個非常複雜的工程。不過，在雲原生時代，雲平台所提供的雲原生資料庫服務可以解決大部分複雜的分布式系統問題，是以，如果企業是通過雲平台提供的能力來建構彈性系統，自然就會擁有資料庫系統的彈性能力。
- 自動化部署
系統突發流量通常無法預計，是以常用的解決方案是，通過人工擴容系統的方式，使系統具備支援更大規模使用者通路的能力。在完成架構拆分之後，彈性系統還需要具備自動化部署能力，以便根據既定的規則或者外部流量突發信号觸發系統的自動化擴容功能，滿足系統對于縮短突發流量影響時長的及時性要求，同時在峰值時段結束後自動縮容系統，降低系統運作的資源占用成本。
- 支援服務降級
彈性系統需要提前設計異常應對方案，比如，對服務進行分級治理，在彈性機制失效、彈性資源不足或者流量峰值超出預期等異常情況下，系統架構需要具備服務降級的能力，通過降低部分非關鍵服務的品質，或者關閉部分增強功能來讓出資源，并擴容重要功能對應的服務容量，以確定産品的主要功能不受影響。
國内外已有很多成功建構大規模彈性系統的實踐案例，其中最具代表性的是阿裡巴巴一年一度的“雙11”大促活動。為了應對相較于平時上百倍的流量峰值，阿裡巴巴每年從阿裡雲采買彈性資源部署自己的應用，并在“雙 11”活動之後釋放這一批資源，按需付費，進而大幅降低大促活動的資源成本。另一個例子是新浪微網誌的彈性架構，在社會熱點事件發生時，新浪微網誌通過彈性系統将應用容器擴容到阿裡雲，以應對熱點事件導緻的大量搜尋和轉發請求。系統通過分鐘級的按需擴容響應能力，大幅降低了熱搜所産生的資源成本。
随着雲原生技術的發展，FaaS、Serverless 等技術生态逐漸成熟，建構大規模彈性系統的難度逐漸降低。當企業以 FaaS、Serverless 等技術理念作為系統架構的設計原則時，系統就具備了彈性伸縮的能力，企業也就無須額外為“維護彈性系統自身”付出成本。
可觀測原則
與監控、業務探活、APM（Application Performance Management，應用性能管理）等系統提供的被動能力不同，可觀測性更強調主動性，在雲計算這樣的分布式系統中，主動通過日志、鍊路跟蹤和度量等手段，讓一次 App 點選所産生的多次服務調用耗時、傳回值和參數都清晰可見，甚至可以下鑽到每次第三方軟體調用、SQL 請求、節點拓撲、網絡響應等資訊中。運維、開發和業務人員通過這樣的觀測能力可以實時掌握軟體的運作情況，并獲得前所未有的關聯分析能力，以便不斷優化業務的健康度和使用者體驗。
随着雲計算的全面發展，企業的應用架構發生了顯著變化，正逐漸從傳統的單體應用向微服務過渡。在微服務架構中，各服務之間松耦合的設計方式使得版本疊代更快、周期更短；基礎設施層中的 Kubernetes 等已經成為容器的預設平台；服務可以通過流水線實作持續內建與部署。這些變化可将服務的變更風險降到最低，提升了研發的效率。
在微服務架構中，系統的故障點可能出現在任何地方，是以我們需要針對可觀測性進行體系化設計，以降低 MTTR（故障平均修複時間）。
要想建構可觀測性體系，需要遵循如下三個基本原則。
- 資料的全面采集
名額（Metric）、鍊路跟蹤（Tracing）和日志（Logging）這三類資料是建構一個完整的可觀測性系統的“三大支柱”。而系統的可觀測性就是需要完整地采集、分析和展示這三類資料。
（1）名額
名額是指在多個連續的時間周期裡用于度量的 KPI 數值。一般情況下，名額會按軟體架構進行分層，分為系統資源名額（如 CPU 使用率、磁盤使用率和網絡帶寬情況等）、應用名額（如出錯率、服務等級協定 SLA、服務滿意度 APDEX、平均延時等）、業務名額（如使用者會話數、訂單數量和營業額等）。
（2）鍊路跟蹤
鍊路跟蹤是指通過 TraceId 的唯一辨別來記錄并還原發生一次分布式調用的完整過程，貫穿資料從浏覽器或移動端經過伺服器處理，到執行 SQL 或發起遠端調用的整個過程。
（3）日志
日志通常用來記錄應用運作的執行過程、代碼調試、錯誤異常等資訊，如 Nginx 日志可以記錄遠端 IP、發生請求時間、資料大小等資訊。日志資料需要集中化存儲，并具備可檢索的能力。
- 資料的關聯分析
讓各資料之間産生更多的關聯，這一點對于一個可觀測性系統而言尤為重要。出現故障時，有效的關聯分析可以實作對故障的快速定界與定位，進而提升故障處理效率，減少不必要的損失。一般情況下，我們會将應用的伺服器位址、服務接口等資訊作為附加屬性，與名額、調用鍊、日志等資訊綁定，并且賦予可觀測系統一定的定制能力，以便靈活滿足更加複雜的運維場景需求。
- 統一監控視圖與展現
多種形式、多個次元的監控視圖可以幫助運維和開發人員快速發現系統瓶頸，消除系統隐患。監控資料的呈現形式應該不僅僅是名額趨勢圖表、柱狀圖等，還需要結合複雜的實際應用場景需要，讓視圖具備下鑽分析和定制能力，以滿足運維監控、版本釋出管理、故障排除等多場景需求。
随着雲原生技術的發展，基于異構微服務架構的場景會越來越多、越來越複雜，而可觀測性是一切自動化能力建構的基礎。隻有實作全面的可觀測性，才能真正提升系統的穩定性、降低 MTTR。是以，如何建構系統資源、容器、網絡、應用、業務的全棧可觀測體系，是每個企業都需要思考的問題。
韌性原則
韌性是指當軟體所依賴的軟硬體元件出現異常時，軟體所表現出來的抵禦能力。這些異常通常包括硬體故障、硬體資源瓶頸（如 CPU 或網卡帶寬耗盡）、業務流量超出軟體設計承受能力、影響機房正常工作的故障或災難、所依賴軟體發生故障等可能造成業務不可用的潛在影響因素。
業務上線之後，在運作期的大部分時間裡，可能還會遇到各種不确定性輸入和不穩定依賴的情況。當這些非正常場景出現時，業務需要盡可能地保證服務品質，滿足目前以聯網服務為代表的“永遠線上”的要求。是以，韌性能力的核心設計理念是面向失敗設計，即考慮如何在各種依賴不正常的情況下，減小異常對系統及服務品質的影響并盡快恢複正常。
韌性原則的實踐與常見架構主要包括服務異步化能力、重試 / 限流 / 降級 / 熔斷 / 反壓、主從模式、叢集模式、多 AZ（Availability Zone，可用區）的高可用、單元化、跨區域（Region）容災、異地多活容災等。
下面結合具體案例詳細說明如何在大型系統中進行韌性設計。“雙 11”對于阿裡巴巴來說是一場不能輸的戰役，是以其系統的設計在政策上需要嚴格遵循韌性原則。例如，在統一接入層通過流量清洗實作安全政策，防禦黑産攻擊；通過精細化限流政策確定峰值流量穩定，進而保障後端工作正常進行。為了提升全局的高可用能力，阿裡巴巴通過單元化機制實作了跨區域多活容災，通過同城容災機制實作同城雙活容災，進而最大程度提升 IDC（Internet Data Center，網際網路資料中心）的服務品質。在同一 IDC 内通過微服務和容器技術實作業務的無狀态遷移；通過多副本部署提高高可用能力；通過消息完成微服務間的異步解耦以降低服務的依賴性，同時提升系統吞吐量。從每個應用的角度，做好自身依賴梳理，設定降級開關，并通過故障演練不斷強化系統健壯性，保證阿裡巴巴“雙11”大促活動正常穩定進行。
随着數字化程序的加快，越來越多的數字化業務成為整個社會經濟正常運轉的基礎設施，但随着支撐這些數字化業務的系統越來越複雜，依賴服務品質不确定的風險正變得越來越高，是以系統必須進行充分的韌性設計，以便更好地應對各種不确定性。尤其是在涉及核心行業的核心業務鍊路（如金融的支付鍊路、電商的交易鍊路）、業務流量入口、依賴複雜鍊路時，韌性設計至關重要。
所有過程自動化原則
技術是把“雙刃劍”，容器、微服務、DevOps 以及大量第三方元件的使用，在降低分布式複雜性和提升疊代速度的同時，也提高了軟體技術棧的複雜度，加大了元件規模，進而不可避免地導緻了軟體傳遞的複雜性。如果控制不當，應用就會無法體會到雲原生技術的優勢。通過 IaC、GitOps、OAM、Operator 和大量自動化傳遞工具在 CI/CD（持續內建 /持續傳遞）流水線中的實踐，企業可以标準化企業内部的軟體傳遞過程，也可以在标準化的基礎上實作自動化，即通過配置資料自描述和面向終态的傳遞過程，實作整個軟體傳遞和運維的自動化。
要想實作大規模的自動化，需要遵循如下四個基本原則。
- 标準化
實施自動化，首先要通過容器化、IaC、OAM 等手段，标準化業務運作的基礎設施，并進一步标準化對應用的定義乃至傳遞的流程。隻有實作了标準化，才能解除業務對特定的人員和平台的依賴，實作業務統一和大規模的自動化操作。
- 面向終态
面向終态是指聲明式地描述基礎設施和應用的期望配置，持續關注應用的實際運作狀态，使系統自身反複地變更和調整直至趨近終态的一種思想。面向終态的原則強調應該避 免直接通過工單系統、工作流系統組裝一系列過程式的指令來變更應用，而是通過設定終态，讓系統自己決策如何執行變更。
- 關注點分離
自動化最終所能達到的效果不隻取決于工具和系統的能力，更取決于為系統設定目标的人，是以要確定找到正确的目标設定人。在描述系統終态時，要将應用研發、應用運維、基礎設施運維這幾種主要角色所關注的配置分離開來，各個角色隻需要設定自己所關注和擅長的系統配置，以便確定設定的系統終态是合理的。
- 面向失敗設計
要想實作全部過程自動化，一定要保證自動化的過程是可控的，對系統的影響是可預期的。我們不能期望自動化系統不犯錯誤，但可以保證即使是在出現異常的情況下，錯誤的影響範圍也是可控的、可接受的。是以，自動化系統在執行變更時，同樣需要遵循人工變更的最佳實踐，保證變更是可灰階執行的、執行結果是可觀測的、變更是可快速復原的、變更影響是可追溯的。
業務執行個體的故障自愈是一個典型的過程自動化場景。業務遷移到雲上後，雲平台雖然通過各種技術手段大幅降低了伺服器出故障的機率，但是卻并不能消除業務本身的軟體故障。軟體故障既包括應用軟體自身的缺陷導緻的崩潰、資源不足導緻的記憶體溢出（OOM）和負載過高導緻的夯死等異常問題，也包括核心、守護程序（daemon 程序）等系統軟體的問題，更包括混部的其他應用或作業的幹擾問題。随着業務規模的增加，軟體出現故障的風險正變得越來越高。傳統的運維故障處理方式需要運維人員的介入，執行諸如重新開機或者騰挪之類的修複操作，但在大規模場景下，運維人員往往疲于應對各種故障，甚至需要連夜加班進行操作，服務品質很難保證，不管是客戶，還是開發、運維人員，都無法滿意。
為了使故障能夠實作自動化修複，雲原生應用要求開發人員通過标準的聲明式配置，描述應用健康的探測方法和應用的啟動方法、應用啟動後需要挂載和注冊的服務發現以及配置管理資料庫（Configuration Management Data Base，CMDB）資訊。通過這些标準的配置，雲平台可以反複探測應用，并在故障發生時執行自動化修複操作。另外，為了防止故障探測本身可能存在的誤報問題，應用的運維人員還可以根據自身容量設定服務不可用執行個體的比例，讓雲平台能夠在進行自動化故障恢複的同時保證業務可用性。執行個體故障自愈的實作，不僅把開發人員和運維人員從煩瑣的運維操作中解放了出來，而且可以及時處理各種故障，保證業務的連續性和服務的高可用性。
零信任原則
基于邊界模型的傳統安全架構設計，是在可信和不可信的資源之間架設一道牆，例如，公司内網是可信的，而網際網路則是不可信的。在這種安全架構設計模式下，一旦入侵者滲透到邊界内，就能夠随意通路邊界内的資源了。而雲原生架構的應用、員工遠端辦公模式的普及以及用手機等移動裝置處理工作的現狀，已經完全打破了傳統安全架構下的實體邊界。員工在家辦公也可以實作與合作方共享資料，因為應用和資料被托管到了雲上。
如今，邊界不再是由組織的實體位置來定義，而是已經擴充到了需要通路組織資源和服務的所有地方，傳統的防火牆和 VPN 已經無法可靠且靈活地應對這種新邊界。是以，我們需要一種全新的安全架構，來靈活适應雲原生和移動時代環境的特性，不論員工在哪裡辦公，裝置在哪裡接入，應用部署在哪裡，資料的安全性都能夠得到有效保護。如果要實作這種新的安全架構，就要依托零信任模型。
傳統安全架構認為防火牆内的一切都是安全的，而零信任模型假設防火牆邊界已經被攻破，且每個請求都來自于不可信網絡，是以每個請求都需要經過驗證。簡單來說，“永不信任，永遠驗證”。在零信任模型下，每個請求都要經過強認證，并基于安全政策得到驗證授權。與請求相關的使用者身份、裝置身份、應用身份等，都會作為核心資訊來判斷請求是否安全。
如果我們圍繞邊界來讨論安全架構，那麼傳統安全架構的邊界是實體網絡，而零信任安全架構的邊界則是身份，這個身份包括人的身份、裝置的身份、應用的身份等。要想實作零信任安全架構，需要遵循如下三個基本原則。
- 顯式驗證
對每個通路請求都進行認證和授權。認證和授權需要基于使用者身份、位置、裝置資訊、服務和工作負載資訊以及資料分級和異常檢測等資訊來進行。例如，對于企業内部應用之間的通信，不能簡單地判定來源 IP是内部 IP 就直接授權通路，而是應該判斷來源應用的身份和裝置等資訊，再結合目前的政策授權。
- 最少權限
**對于每個請求，隻授予其在當下必需的權限，且權限政策應該能夠基于目前請求上下文自适應。例如，HR 部門的員工應該擁有通路 HR相關應用的權限，但不應該擁有通路财務部門應用的權限。
- 假設被攻破
假設實體邊界被攻破，則需要嚴格控制安全爆炸半徑，将一個整體的網絡切割成對使用者、裝置、應用感覺的多個部分。對所有的會話加密，使用資料分析技術保證對安全狀态的可見性。
從傳統安全架構向零信任架構演進，會對軟體架構産生深刻的影響，具體展現在如下三個方面。
第一，不能基于 IP 配置安全政策。在雲原生架構下，不能假設 IP 與服務或應用是綁定的，這是由于自動彈性等技術的應用使得 IP 随時可能發生變化，是以不能以 IP 代表應用的身份并在此基礎上建立安全政策。
第二，身份應該成為基礎設施。授權各服務之間的通信以及人通路服務的前提是已經明确知道通路者的身份。在企業中，人的身份管理通常是安全基礎設施的一部分，但應用的身份也需要管理。
第三，标準的釋出流水線。在企業中，研發的工作通常是分布式的，包括代碼的版本管理、建構、測試以及上線的過程，都是比較獨立的。這種分散的模式将會導緻在實際生産環境中運作的服務的安全性得不到有效保證。如果可以标準化代碼的版本管理、建構以及上線的流程，那麼應用釋出的安全性就能夠得到集中增強。
總體來說，整個零信任模型的建設包括身份、裝置、應用、基礎設施、網絡、資料等幾個部分。零信任的實作是一個循序漸進的過程，例如，當組織内部傳輸的所有流量都沒有加密的時候，第一步應該先保證通路者通路應用的流量是加密的，然後再逐漸實作所有流量的加密。如果采用雲原生架構，就可以直接使用雲平台提供的安全基礎設施和服務，以便幫助企業快速實作零信任架構。
架構持續演進原則
如今，技術與業務的發展速度都非常快，在工程實踐中很少有從一開始就能夠被明确定義并适用于整個軟體生命周期的架構模式，而是需要在一定範圍内不斷重構，以适應變 化的技術和業務需求。同理，雲原生架構本身也應該且必須具備持續演進的能力，而不是一個封閉式的、被設計後一成不變的架構。是以在設計時除了要考慮增量疊代、合理化目标選取等因素之外，還需要考慮組織（例如架構控制委員會）層面的架構治理和風險控制規範以及業務自身的特點，特别是在業務高速疊代的情況下，更應該重點考慮如何保證架構演進與業務發展之間的平衡。
- 演進式架構的特點和價值
演進式架構是指在軟體開發的初始階段，就通過具有可擴充性和松耦合的設計，讓後續可能發生的變更更加容易、更新性重構的成本更低，并且能夠發生在開發實踐、釋出實踐和整體靈活度等軟體生命周期中的任何階段。
演進式架構之是以在工業實踐中具有重要意義，其根本原因在于，在現代軟體工程領域達成的共識中，變更都是很難預測的，其改造的成本也極其高昂。演進式架構并不能避免重構，但是它強調了架構的可演進性，即當整個架構因為技術、組織或者外部環境的變化需要向前演進時，項目整體依然能夠遵循強邊界上下文的原則，確定領域驅動設計中描述的邏輯劃分變成實體上的隔離。演進式架構通過标準化且具有高可擴充性的基礎設施體系，大量采納标準化應用模型與子產品化運維能力等先進的雲原生應用架構實踐，實作了整個系統架構在實體上的子產品化、可複用性與職責分離。在演進式架構中，系統的每個服務在結構層面與其他服務都是解耦的，替換服務就像替換樂高積木一樣友善。
- 演進式架構的應用
在現代軟體工程實踐中，演進式架構在系統的不同層面有着不同的實踐與展現。
在面向業務研發的應用架構中，演進式架構通常與微服務設計密不可分。例如，在阿裡巴巴的網際網路電商應用中（例如大家所熟悉的淘寶和天貓等），整個系統架構實際上被精細地設計成數千個邊界劃分明确的元件，其目的就是為希望做出非破壞性變更的開發人員 提供更大的便利，避免因為不适當的耦合将變更導向難以預料的方向，進而阻礙架構的演 進。可以發現，演進式架構的軟體都支援一定程度的子產品化，這種子產品化通常展現為經典的分層架構及微服務的最佳實踐。
而在平台研發層面，演進式架構更多地展現為基于“能力”的架構( Capability Oriented Architecture，COA)。在 Kubernetes 等雲原生技術逐漸普及之後，基于标準化的雲原生基礎設施正迅速成為平台架構的能力提供方，而以此為基礎的開放應用模型( Open ApplieationModel，OAM )理念，正是一種從應用架構視角出發，将标準化基礎設施按照能力進行子產品化的 COA 實踐。
- 雲原生下的架構演進
目前，演進式架構還處于快速成長與普及階段。不過，整個軟體工程領域已經達成共識，即軟體世界是不斷變化的，它是動态而非靜态的存在。架構也不是一個簡單的等式，它是持續過程的一種快照。是以無論是在業務應用還是在平台研發層面，演進式架構都是一個必然的發展趨勢。業界大量架構更新的工程實踐都诠釋了一個問題，即由于忽略實作架構，且保持應用常新所要付出的精力是非常巨大的。但好的架構規劃可以幫助應用降低新技術的引入成本，這要求應用與平台在架構層面滿足:架構标準化、職責分離與子產品化。而在雲原生時代，開發應用模型( OAM )正在迅速成為演進式架構推進的重要助力。
如果你想開發小程式或者app的話，可以通過第三方專業開發平台，來幫助你實作開發需求：
廈門在乎科技-專注小程式開發、
廈門app開發公司、網站開發
![更改LYNC SIP位址[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)