部署MVC架構的Web應用程序，即從頭到尾的發展史，來嘍！

瀾夢IT攻略，我們來了！

使用 MVC 架構部署 Web 應用程序后的典型情況。 上圖中整個藍色部分是服務端邊界，負責應用或代碼的在線運維。 所要解決的問題的邊界是服務器端的邊界，即服務器端的運維。

那么，我們先來看看服務端運維的發展史，也就是從頭到尾的發展史。 假設有一個 Web 應用程序。 開發此 Web 應用程序涉及開發工程師和運輸工程師的角色。 研發工程師只關心應用的業務邏輯。 具體來說，在整個基于MVC的Web應用開發中，從服務端接口View層到業務邏輯層、數據存儲Model層、Web應用的整體版本管理和在線bug修復、運維工程師只關心適用的服務端運維。 事務。 負責部署在線小程序web應用，綁定域名，監控日志。 當用戶訪問量大的時候，他就會擴展這個應用。 當用戶流量低的時候，他會收縮應用。 當服務器停止時，他重新啟動或更換服務器。

時代。 最初，研發工程師不需要擔心與部署相關的事情。 每當研發工程師發布新應用時，運營工程師負責將最新代碼上線。 傳輸維護工程師必須管理迭代版本發布、分支合并、實時應用程序和問題回滾。 如果在線出現問題，則必須記錄日志并將其發送給開發工程師。

Era 完全隔離了研究開發和運輸維度。 這種完全隔離的好處是顯而易見的：研發工程師可以專注于自己的業務，而運維工程師則變成了工具工人，處理大量的運維工作和大量的瑣事。

時代。 運維工程師發現，很多事情都是重復性的工作。 萬一網上出現故障，他們還得抓日志發給研發工程師，效率很低。 因此，運維工程師開發了一系列的運維控制臺，讓研發工程師可以處理在線導入和日志抓取的工作。

這讓運維工程師輕松了一點，但是架構優化和資源擴容計劃必須要負責。 除了開發任務IT外包服務，開發工程師還會從傳輸維度控制臺發布新版本來解決在線故障。 這時候就是開發和運維，研發工程師也是運維工程師的一部分工作，但是這部分工作應該由研發工程師負責（比如版本管理，在線故障等）。 而且，運維工程師工具化這部分工作，效率更高，趨向于更少。 工業時代。 運維工程師也可以根據研發工程師的開發流程進一步完善運維控制臺，實現代碼的自動發布：掃碼-測試-灰度驗證-上線。 這樣，開發工程師只需要將最新的代碼合并到Git倉庫指定的分支中，剩下的由代碼自動發布的管道負責。 這個時候研發工程師不需要運維。 沒有 NoOps，研發工程師又回到了起點。 您只需要關心您的應用業務。

運營工程師還可以發現資源優化和可擴展性場景，并利用性能監控流量來估計解決方案。 這樣，運維工程師的運維工作也實現了全自動化。 那么對于研發工程師來說，運維工程師的存在感越來越弱，運維工程師要做的事情越來越少，被自動化工具所取代。 這是。

未來。 實現無運維后，運維工程師必須提供更多的基礎服務IT外包服務，建設基礎設施，提供更智能、更省資源、更周到的服務。 研發工程師完全不用擔心運輸維度，可以專心處理自己的業務，提升用戶體驗，考慮商業價值。

無運維NoOps并不是說服務端運維不存在，而是通過無所不知、無所不能的服務覆蓋研發引入的所有需求，讓研發工程師越來越不了解它。 另外，NoOps是一種理想狀態，我們可以無限接近NoOps，所以可以說less不是。

定義了解決問題的邊界，即服務端的運維。 less說明了解決問題的目的，即沒有運輸NoOps。 所以應該叫服務端空跑維度，這才是需要解決的問題。

什么是無服務器

需要解決的是讓運維工程師的工作完全透明。 研發工程師只關心業務邏輯，不需要關心傳輸和在線維護的各種問題。 為了達到這種狀態，意味著網絡服務器的整體運維工作是極其抽象的。 越是抽象的東西，它包含的信息量就越大，所以很難定義。

但總的來說，是指以下兩種。

狹義上（最常見）是指架構=FaaS架構=（事件驅動）FAS（ as a ）BAS（BAS）廣義上是指服務端非運維，即，具有特色的云服務。

文/上海瀾夢IT外包專家