雲原生應用是 Matt Stine 提出的一個概念,出如今其 Migrate to cloud Native App Architectures 一書中。
<!-- more --> html
CloudNative 是一個思想的集合,包括 DevOps、持續交付(Continuous Delivery)、微服務(MicroServices)、敏捷基礎設施(Agile Infrastructure)、康威定律(Conways Law)等,以及根據商業能力對公司進行重組。Cloud Native 既包含技術(微服務,敏捷基礎設施),也包含管理(DevOps,持續交付,康威定律,重組等)。Cloud Native也能夠說是一系列 Cloud 技術、企業管理方法的集合。git
Cloud speed up the rate of creating, CloudNative is the way.
以容器爲基礎,提升總體開發水平,造成代碼和組件重用,簡化雲原生應用程序的維護。在容器中運行應用程序和進程,並做爲應用程序部署的獨立單元,實現高水平資源隔離。github
統一調度和管理中心,從根本上提升系統和資源利用率,同時下降運維成本。segmentfault
經過鬆耦合方式,提高應用程序的總體敏捷性和可維護性。安全
業務部門一般會根據本身的業務發展規劃資源需求,如起初平均只要一臺設備,但考慮突發業務峯值,以及後續擴容,一般會冗餘3~5倍左右的資源,這部分資源幾乎沒法被共享使用。而最近幾年出現了虛擬化技術後,理論上基於VM的方式對這個問題有所改善,但仍然存在業務部門申請虛擬機後無人主動釋放的問題,人爲因素仍然形成設備資源利用率低。服務器
通常中小企業應用開發相對粗放,開發自行搭建環境,開發後代碼給測試,而測試一般也要維護一套相同的運行環境,對每次測試配置應用和環境,容易引發兩邊不一致,形成測試質量降低。一樣的問題也容易發生在部署上線,並可能形成更大的線上故障。架構
傳統應用開發一般容易形成後續業務發展代碼和系統結構高度耦合,繼而影響整個開發團隊合做,形成組織龐大,分工混亂。同時在新功能開發迭代、問題排查上牽一髮而動全身,新功能上線替換式升級,須要中斷線上業務,形成總體系統可用性很低;發佈上線自己還可能附帶BUG風險高,隨着時間,人員變更調整,每一個企業都有一堆沒法維護的毒瘤代碼;在運維上,單體應用幾乎幾法擴容,隨着業務發展,只能限於縱向擴容,盲目提高硬件設備能力,購置昂貴的高端服務器,運維成本愈來愈高。app
在以前,咱們介紹過 12-Factor 原則。它是針對雲原生應用開發的最佳實踐原則。這些原則帶來的是應用的可移植、自動化、效率提高,促進開發、測試、運維、文化、組織、技術、整個範圍的變革,進而幫助企業IT轉型,成爲市場競爭中真正敏捷的力量,得到優於競爭對手的效率、成本優點。運維
Authing 的總體開發架構遵循 CloudNative 思想。這爲咱們和咱們的客戶帶來了極大的靈活性、高可用性和可擴展性。成爲咱們 30+ 倍效率提高的關鍵。ide
Authing 的目標:致力於提升社會生產力。經過 Authing 推進雲原生應用在中國落地,讓Authing 成爲受開發者歡迎的身份認證工具,終端用戶喜歡的身份數據品牌。
技術的進步帶來軟件開發愈來愈往更高一層抽象發展,以達到更高靈活。咱們有理由相信將來的軟件開發也能夠抽像到現在的硬件組裝同樣,賦予每個終端用戶更多創造力可能,那時 Authing 將相似你在現時世界看到的 「Inter Inside」。
最後,雖然雲原生應用不可能在全部應用場景都完美適配,但在雲計算髮展到今天的這個時代,尤爲你是一個互聯網或小的團隊創業者,雲原生(CloudNative)這個理念,你值得擁抱!
Authing 提供專業的身份認證和受權服務。
咱們爲開發者和企業提供用以保證應用程序安全所需的認證模塊,這讓開發人員無需成爲安全專家。
你能夠將任意平臺的應用接入到 Authing(不管是新開發的應用仍是老應用均可以),同時你還能夠自定義應用程序的登陸方式(如:郵箱/密碼、短信/驗證碼、掃碼登陸等)。
你能夠根據你使用的技術,來選擇咱們的 SDK 或調用相關 API 來接入你的應用。當用戶發起受權請求時,Authing 會幫助你認證他們的身份和返回必要的用戶信息到你的應用中。
![]()
<div align=center>Authing 在應用交互中的位置</div>
倉庫: 歡迎 Star,歡迎 PR
Demo: