B/S架構的軟件配置的分類與管理

B/S架構的軟件配置的分類與管理

前言

本文分享B/S架構軟件配置的分類與管理的一些實踐經驗。在開始本文以前,先來看看下面幾個場景中涉及到的配置,究竟是由運維人員仍是運營人員來操做呢?html

場景一:git

在線購物網站,雙十一因爲訂單火爆,爲了防止惡意刷單,如今須要將訂單系統下單接口的QPS配置閾值調低進行限流。github

場景二:spring

在線購物網站,雙十一因爲訂單火爆,快遞運輸能力有限,如今須要在下單時發佈一個公告,提醒用戶快遞發貨須要延遲1~2工做日。數據庫

場景三:瀏覽器

在線購物網站,雙十一大促,決定指定某類型商品用戶下單可使用花唄支付,如今須要開啓該類商品的花唄支付通道安全

運維與運營的區別

在回答上面問題以前,咱們先看看運維和運營在崗位職責上的區別?網絡

運維 運營
方向 技術方向 業務方向
目標 系統穩定運行爲導向 客戶價值爲導向
工做內容 業務架構底層支撐,保障IT系統運行 圍繞產品,多種運做(用戶增加,留存,促活,轉化)
關注點 偏技術 偏業務
能力要求 更強調技術能力 更強調規劃和營銷能力

經過了解了運維與運營的區別以後,上面的問題應該比較好回答了,下面表格中給出來答案和分析。架構

場景 操做配置的角色 分析
場景一 運維 QPS限流專業問題,維護系統穩定性
場景二 運營 業務場景須要,提高用戶體驗
場景三 運營 業務場景須要,增長交易量

上面三個場景涉及到的配置相對比較容易辨識應該是由運維仍是運營來操做。然而實際開發中,研發人員面對比較多的配置定義時,容易忽略配置的使用場景或者對其具體的操做人理解有誤,從而致使配置的管理上出現誤差。負載均衡

軟件配置的分類

軟件配置分類策略

在進行軟件分類以前,先了解一些B/S(Browser/Server)架構的軟件配置相關的特色。

  • 用戶經過瀏覽器訪問服務端,服務端的改進和升級,用戶端不須要關注或者升級。
  • 一般服務端的改進和升級可能伴隨着新功能的發佈,BUG修復,亦或者用戶端看到的內容或者頁面有變化,都會涉及一系列的配置。好比:服務端升級,則是運維人員從新部署了新版本軟件;用戶打開瀏覽器看到網頁上出現了國慶慶典的Banner圖,則是運營人員在服務端的運營平臺上發起了節日提醒配置。

爲了能有效的對軟件配置進行管理,咱們能夠根據配置的維護人的角度將配置分爲兩大類:

  • 運維配置
  • 運營配置

什麼是運維配置

運維配置是:軟件(服務)正常穩定可靠運行的必要配置,這些配置一般來自非功能性需求,關注點在技術實現上,跟運維人員相關。

下面列舉一些能夠認爲是運維配置的內容:

  • 軟件依賴的數據庫地址,用戶命,密碼(正常運行的必要配置)
  • 數據庫鏈接池的配置參數(爲性能,軟件穩定運行)
  • 負載均衡配置(流量轉發)
  • 服務健康檢查配置(健康服務的健康狀態,及時做出處理)

什麼是運營配置

運維配置:軟件(服務)正常運行過程當中,因爲要達成不一樣業務場景,不一樣運營活動,不一樣的權限,不一樣的使用習慣等業務目標,須要經過運行時修改程序的一些配來實現置,這些配置一般來自功能性需求,關注點在業務場景和功能上,跟運營人員相關。

備註:有時候爲了軟件(服務)的易用性,也會經過增長運營配置來知足這一非功能性需求。

下面列舉一些能夠認爲是運營配置的內容:

  • 爲在線購物網站配置一個新的支付方式,用戶在下單支付時能夠選擇新的支付方式進行支付

  • 在線購物網站的客服聯繫方式變動

  • WordPress博客系統更換一下主題風格,設置一下做者的聯繫方式

備註:定義一個概念是很是困難的,雖然上文中定義了運維配置和運營配置,僅供參考,以避免引發紛爭。好比:NoSQL,微服務等概念最初的描述也不是特別的明確,隨着更多業內人士的討論,實踐才達成了必定的共識。

爲何沒有研發配置

上面提到運維配置,運營配置,那爲何沒有研發配置呢?這個問題比較好回答。

首先答案是:沒有研發配置。理由以下:研發所交付的是可工做的軟件,可工做的軟件所依賴的基礎設施以及基礎設施(網絡,數據庫,磁盤,端口)的配置是運維的工做範疇。運營配置是在運維提供可運行的軟件的基礎上進行的。

可能會有人提問道DevOps(開發運做)中的Ops, 開發須要參與到軟件的部署維護工做中,可是咱們仍然要明確一個事情那就是DevOps是擴大的開發人員的工做邊界,Ops中涉及的配置讓屬於運維配置。

配置管理設計思路

軟件研發設計階段關於配置管理的設計須要知足運維和運營兩方面的要求。因爲運維和運營的崗位職責的不一樣,特別是技術和業務背景的不一樣,在配置管理的設計上要充分考慮二者的差別。

配置管理常見設計方案

配置管理常見設計方案不少,本文主要以使用方式來討論的是配置管理的實現,至於配置如何存儲不是本文的關注點。

配置方式 運維配置 運營配置
命令行工具 適合,較爲專業 不適合
配置文件 適合,較爲專業 不適合
可視化界面 適合,提升運維效率 適合,運營人員易用
引導界面 適合,專業程度較高引導運維配置 適合,涉及業務領域知識引導運營配置

這裏重點說一下引導界面,引導界面也稱爲:引導設計。常常用在移動端APP上,目前在Web網站上也大量出現。以下圖示:

B/S架構的軟件配置的分類與管理

按照引導界面實現方式上一般分爲靜態引導界面動態引導界面。配置管理常使用動態引導界面,引導界面在可視化界面的基礎上增長了交互式引導。好比:用戶(運維或運營人員)在首次進行配置時,經過提示用戶該如何進行一步步操做完成其目標;亦或者將引導界面做爲幫助手冊的一部分。

運維配置管理解決方案

因爲運維屬於技術範疇,其涉及到的配置也一般具備必定的通用性。關於運維配置管理解決方案下面列舉幾個:

  • Apollo : 配置管理中心,可以集中化管理應用不一樣環境,不一樣集羣的配置,具有可視化界面操做
  • Nacos:阿里巴巴開源的配置中心
  • Spring Cloud Config: Spring Cloud生態組件的配置中心
  • Disconf : 百度開源的分佈式系統配置管理的通用組件和通用平臺

除了上面例舉的配置管理解決方案外,軟件研發常常也會採用一些分佈式系統中間件來實現配置管理,好比:Zookeeper, Consul,etcd。

下面列舉幾個常見的運維配置管理實現的示例圖:

  • Apollo配置管理界面
    B/S架構的軟件配置的分類與管理
  • Nacos配置管理界面B/S架構的軟件配置的分類與管理

運營配置管理解決方案

很遺憾,運營配置管理沒有標準的解決方案。上文中什麼是運營配置中提到,該類配置一般來自功能性需求,既然是功能性需求,那麼必須從具體業務需求的角度出發去解決運營配置的管理。

不過仍然有一些能夠借鑑和參考的思路。好比:一般會在運營人員參與的系統中增長設置或者系統管理或者運營配置等功能,而後對功能進一步分解實現具體的配置管理。好比:常規設置,個性化配置,支付管理,渠道管理,用戶管理,權限管理等。固然不只限於此。業務功能中經常涉及運營人員參與的配置,好比:站內通知功能,優惠券發放功能等都將包含運營的配置。

下面列舉幾個常見的運營配置管理實現的示例圖:

  • 阿里雲控制檯用戶管理安全設置
    B/S架構的軟件配置的分類與管理
  • WordPress博客系統運營端設置
    B/S架構的軟件配置的分類與管理
  • 常見的系統權限管理
    B/S架構的軟件配置的分類與管理

結尾

本文從軟件配置的分類和配置管理設計兩大方面分享了一些實踐經驗。最後總結一下:研發人員面對功能性需求和非功能需求所涉及的配置,應該儘早的在軟件設計的階段就去考慮配置應該如何劃分與管理;知足運維和運營可以在各自工做範圍內更好的操做配置實現彼此的工做目的要求。

參考文獻

相關文章
相關標籤/搜索