006.不淺談，數十條業務線以上的，前端小團隊瞎逼基礎服務思路

時間  2019-11-24
標籤 淺談 十條 業務 以上 前端 團隊 基礎 服務 思路 简体版
原文   原文鏈接

！！！高能預警，長文，我都不知道多少字。css

背景html

我嘛，雖然不是出身bat，寫了三年多業務代碼，18年開始帶團隊至今，從toB的pc、管理臺、小程序、微信公衆號、app、活動、服務端，都有涉獵。固然公司小，我這種人就是跟着公司一點一點成長起來的，沒有前人栽樹，只能本身動手，天資不夠，只能靠肝。大概在17年末的時候，帶個人老大（老大呀，看到文章別diss我）離職了，我就這樣被趕鴨子上架（其實個人心態是崩潰的，沒玩過呀）作了起了前端負責人，後來經歷老員工離職，招聘，新員工入職，公司明確業務，業務量爆發，前端業務線暴漲以後，有幸作一些簡單的基礎服務，這套東西能讓3個前端，應付10條以上業務線，我能夠自豪的說1年多以來，單季度，bug數<=一、技術問題延期<=0。經歷了百來個活動頁，3個移動端，8個管理臺，1個pc商城，2個小程序，上千萬的pv，各類瞎逼狀況慢慢磨練出來的。歷時至今，1年半的時間，我算是作出了一些，我想作的事情。前端

目前全公司涉及前端業務線vue

  • mobile 3條node

    • 商城性質
    • 管理性質
    • 活動性質

  • 小程序 2條react

    • 商城性質
    • 備用小程序

  • pc端 9條webpack

    • 對外商城性質
    • 對外數據管理臺
    • 內部運營管理臺
    • 內部自營管理臺
    • 內部財務管理臺
    • 半內半外的招商管理臺
    • 對外第三方商家管理臺
    • 舊，運營管理臺
    • 舊，招商管理臺

基礎服務

技術棧選擇

  • 移動端

技術棧選擇Vue全家桶，從個人視角來講，移動端的交互不會特別複雜，最多sku選擇、地址、動畫，並且這一塊大部分都是純面向用戶的需求，很難作業務收束，並且很難解耦。基於個人思考，我就想到vue了，輕便、簡單、插件豐富，vue知足個人全部需求。說簡單點，我一個業務new個Vue對象，寫一堆配置/方法就搞定了。活動的話，我選擇了nuxt，活動這種輕便的東西，我靜態化就行了。ios

  • pc端

技術棧選擇React全家桶，從個人視角來講，pc端我面向的都是管理臺需求居多，涉及的交互可能會相對而言複雜，會有拖拽、富文本、頁面編輯、圖表等等交互出現，這個時候React這種以Component爲基本單位的庫對於這類業務來講，就很舒服了，解耦不要太爽。nginx

  • 小程序用原生

我這邊就只有微信小程序，原生確實夠用了，並且原生小程序框架也愈來愈強大，等須要擴展渠道時，我再選擇Taro、mpVue等東西。git

  • npm

請搭建私有的npm，能夠作到公共方法的收集，集中化處理。

  • mock平臺

搭建0業務入侵的mock平臺。

  • nginx管理

集中管理前端的nginx。

  • git倉庫

gitlab天下第一。

  • 項目模版

將vue、react根據業務，製做爲基礎模版，之後展開新業務直接copy便可。

  • 持續發佈

jekins天下第一

  • eslint

服務器初始化

  • 腳本

總結：其實最有爭議的應該是技術棧的選擇了，爲啥要既有vue、又有react、還有小程序、nuxt，很差意思，我以爲在不一樣場景下，使用不一樣的庫是合理的。而且做爲一個程序員，你的學習能力跟不上，那你仍是本身走吧。我還沒上typeScript、Rx.js呢。還有就是招聘問題，很差意思，當面試者問我公司前端技術棧時，大部分都躍躍欲試。成本吧，反正不貴。

具體實現

這裏我只對，nginx管理、私有的npm、mock平臺、項目模版、服務器初始化，作詳細具體解釋。其他的提一點，就不作解釋了，由於jekins就是配置，這個業務性太強，eslint沒啥講的，git倉庫也沒啥講的，小程序原生、pc端、移動端這都是純業務的東西，也沒啥講的。

nginx管理

新建nginxConfig文件夾，目錄結構以下。

nginxConfig
|----- build.sh                                 # 腳本
|----- server.develop.xxxx.com.conf             # 對外服務的nginx配置
|----- server.develop.xxxx.com.ssl.conf         # 對外服務的nginx，https配置
|----- server.test.xxxx.com.conf                # 測試服務器的nginx配置，涵蓋全部業務
|----- server.test.xxxx.com.ssl.conf            # 測試服務器的nginx，https配置，涵蓋全部業務
|----- server.admin.xxxx.com.conf               # 管理臺的nginx配置
|----- server.admin.xxxx.com.conf.ssl.conf      # 管理臺的nginx，https配置
複製代碼

請善用腳本，其實我只須要將nginx，發佈到服務器上面根據不一樣服務器，cp不一樣nginx配置，而後relaod便可。nginx重啓失敗我卻是沒有碰過，我用這套已經部署了n臺活動服務器、n臺管理臺服務器。固然，寫nginx時請在測試服務器謹慎測試。我通常是凌晨三、4點去折騰的，誰叫我肝好呢。

附上腳本代碼

# /bin/bash
echo "請選擇你要替換的nginx"
echo "1) 替換xxxx，nginx"
echo "2) 替換xxxx，https的nginx"
echo "3) 替換xxxx，的nginx"
echo "4) 替換xxxx，https的nginx"
echo "5) 替換xxxx，的nginx"
echo "6) 替換xxxx，https的nginx"

read number
case $number in
1)
  echo "替換xxxx，http的nginx"
  \cp server.admin.xxxx.com.conf /etc/nginx/conf.d/
  service nginx -reload
;;
2)
  echo "替換xxxx，https的nginx"
  \cp server.admin.xxxx.com.ssl.conf /etc/nginx/conf.d/
  service nginx -reload
;;
3)
  echo "替換xxxx的nginx"
  \cp server.test.xxxx.com.conf /etc/nginx/conf.d/
  service nginx -reload
;;
4)
  echo "替換xxxx，https的nginx"
  \cp server.test.xxxx.com.ssl.conf /etc/nginx/conf.d/
  service nginx -reload
;;
5)
  echo "替換xxxx的nginx"
  \cp server.develop.xxxx.com.conf /etc/nginx/conf.d/
  service nginx -reload
;;
6)
  echo "替換xxxx，https的nginx"
  \cp server.develop.xxxx.com.ssl.conf /etc/nginx/conf.d/
  service nginx -reload
;;
esac
複製代碼

告訴你經過腳本編寫好處，別看我如今雖然是手動到服務器上去git pull 而後sh build腳本，我徹底能夠無縫的切到jekins，由於我是腳本呀，配置執行命令就行了呀。我把輸入判斷改成常量不就行了麼。

nginx配置

我只作了最簡單nginx配置，沒有優化，我還沒空去細緻研究，其實這一層還能作不少。可是我簡單的需求就是，經過域名的路徑去匹配頁面，而後proxy。固然我不是單一項目，而是多項目，這裏會涉及正則。

附上例子代碼

server {
  listen 80;
  server_name _;
  charset utf-8;
  access_log /var/www/log/nginx_access.log main;
  error_log /var/www/log/nginx_error.log main;
  root /var/www/html/xxxx/;
  index index.html;

  location ^~ /api-xxx {
    proxy_pass http://www.xxxxx.com;
  }

  location ^~ /api-xxx {
    proxy_pass http://www.xxxxx.com;
  }

  location ^~ /aaa {
    alias /xxxx;
    try_files $uri /xxx/index.html;
    index index.html;
  }

  location ^~ /ccc {
    alias /xxxx;
    try_files $uri $uri/index.html $uri/ =404;
    index index.html;
  }
}
複製代碼

首先，我這邊可能會有www.xxx.com/h5，www.xxx.com/admin的狀況，並且我會根據/api-xxx的不一樣，去請求不一樣的服務。location ^~ /aaa 是針對spa的配置，location ^~ /ccc是針對靜態化頁面的配置。爲啥我不用cdn去緩存html頁面呢？很差意思業務問題不贅述。上述只是例子代碼，你能夠看思路，可別直接在線上用，業務不一樣需求不一樣。

總結：善用腳本解決問題，減小重複勞動。

mock平臺

首先你mock的平臺最好作到0業務入侵，只切換變量便可，要配合好註釋and文檔。個人端口可能面對pc、mobile、小程序等。首先瀏覽器端，我會針對webpack的開發配置作改動。小程序我會二次封裝wx.request。具體實現例子以下。

全部瀏覽器端

// 開發環境 webpack dev server配置
const PATH = require('../package.json').conf_liberty['path'];
const URL = require('../package.json').conf_liberty['url'];

"/api":{
  "target": URL[PATH],
  "pathRewrite": {
    "^/api-xxx": "/xxx",
  }
}
複製代碼
// package.json
"conf_liberty": {
  "path": "mock",
  "url": {
    "mock": "https://xxx.xxx.com/mock/xxx/" ,// mock 數據請求地址
    "test": "http://xxx.test.xxx.com", // 測試機的請求地址
    "pre": "http://xxx.xxx.com/", // 預發佈的請求地址
    "online": "http://xxx.xxx.com/", // 正式環境的請求地址
  }
}
複製代碼

小程序端

// config/url.js
/** * 小程序配置文件、切換環境直接切換變量便可 * @param mock 模擬數據環境 * @param test 測試環境 * @param pre 線上測試環境 * @param online 正式環境 */
const envir = 'online';// 環境閥門
const configMap = {
  'mock': {// mock 數據請求地址
    url: 'https://xxx.xxx.com/mock/xxx/',
  },
  'test': {// 測試機的請求地址
    url: 'http://xxx.test.xxx.com',
  },
  'pre': {// 預發佈的請求地址
    url: 'http://xxx.xxx.com/',
  },
  'online': {// 正式環境的請求地址
    url: 'http://xxx.xxx.com/',
  },
};

const config = configMap[envir];

module.exports = {
  baseUrl: config.url,
};
複製代碼
// 二次封裝的wx.request
// 爲何要封裝成class，由於我有業務擴展，看個思路便可。

import {baseUrl} from '../config/url';

class request {
  request(params) {
    return new Promise((resolve, reject) => {
      let params.url = baseUrl + params.url;
      wx.request({
        ...params,
        success: (result) => {
          //
        },
        fail: (error) => {
          //
        },
        complete: (response) => {
         //
        },
      });
    });
  };

}
export default new request;

複製代碼

每次開發，當開發人員和後端對好接口文檔，到mock服務器寫好mock，而後就能夠在有數據的狀況下愉快的開發了，並且的mock的數據更加全面帶有隨機性質符合前端開發人員需求，須要debug時甚至能夠直接切換線上數據，可是操做線上數據須要時刻注意，這必需要引發開發人員重視。固然帶有上傳性質的接口，不太好測試。可是這點是能夠解決的。須要和後端調試，我切換到test便可，多麼的簡單。我認爲前端的不少的bug問題，都是數據的多樣性致使開發人員沒有考慮到，所帶來的結果。

mock平臺的選擇

首先，我有兩個種作法上的選擇，線上服務器mock，本地服務器mock，我選擇了線上服務器mock作法，由於我mock的數據會愈來愈多，提交到git上真難看，並且本地寫json的形式，對於文檔的整理不太友好，而且業務線確實有點多，須要總線式的管理，全部果斷放棄。

接下來，我對比的easy-mock，yapi，雲效平臺，三種mock服務器平臺以後，我選擇了yapi。先來講說個人標準，內網服務、搭建簡單、升級容易、依賴少、不花錢，另外2種不是很差，只是個人選擇而已。先說說easy-mock的個人見解，麻煩，依賴了Node、MongoDB、Redis，沒有一鍵安裝，一鍵化升級，甚至我還沒找到如何升級，也許我眼拙。雲效平臺，我就看到了簡介，怎麼用我都沒找到，阿里雲的服務嘛，估計還要收費算了。來講說yapi，首先依賴輕，有Node、MongoDB就行了。安裝太簡單npm install -g yapi-cli，執行一下yapi server，配置一下數據庫，點一點就ok了。我就花了1個小時左右就搞定了。後續升級yapi update一下好了。多麼的愉快。並且基本知足個人需求，基本的mock、高級的mock、文檔導入導出很是完美，甚至能測試線上數據，簡單的postman功能也行，連nginx配置官方都幫我想好了。目前我已經在所有業務線使用，並且推薦給客戶端、後端同窗使用，只能說好評連連。並且以我粗淺的能力，尚能看得懂yapi的機制，就算官方不維護了，我也能打打補丁。想知道如何安裝的，去yapi官網看就行了。

安裝方法

來講說個人安裝方法把，首先我會在本地安裝npm install -g yapi-cli，作好基本調試，配置好數據庫，我用的是遠程數據庫。寫好config.json基本配置，而後push到git上。到指定服務器pull便可，安好pm2，啓動。後續升級也是這樣，先本地升級測試一下，而後到服務器pull重啓，固然這是能夠結合jekins。

總結：這種工具服務的選擇沒有啥對錯，只要符合當前業務開發，而且能夠基本的持續迭代便可，自主研發也好，第三方服務也罷，怎麼都行，一切以加速業務開發爲導向。

私有的npm

首先業務線有點多，並且基本能夠作到一些方法複用例如：客戶端版本判斷、UA檢測、統計服務、JSbridge等等，組件二次封裝等。例如：ant design的圖片上傳，你每次寫一堆配置，其實你須要配置的無非是action，disabled，onChange，name你是否是能夠跟後端商量固定action，給一個當前業務的基礎接口作成業務組件。再極端一點，我徹底能夠作成npm包，讓後端同窗提供一個徹底獨立的服務。我發現不少前端，對於UI庫是真拿來主義，拿來就用，拜託，你有沒有發現，其實你每次用UI庫裏面的東西，寫一坨不累麼。人家組件是爲了適應90%場景的，而你在實際業務中所用到可能不到10%。請你提升一下本身的效率可好？

例如：

// 通過二次封裝的上傳組建
let upladFileConf = {
  title: '上傳',// 按鈕內容
  disabled: false,// 是否禁用
  callBack: (e)=> this.handleUpload(e),// 成功回調
  callError: ()=> this.handleError(),// 失敗回調
};
<UpladFile {...upladFileConf}/> 複製代碼
// 通過二次封裝的彈窗組件
const conf = {
  visible: visible,// 是否顯示
  title: '彈窗標題',// 標題
  onCancel: (res)=> this.props.onCancel(res),// 肯定按鈕or取消按鈕，回調
};

return (
  <Modal {...conf}></Modal>
)
複製代碼

私有npm服務選擇

先說個人需求，簡單好用，穩定，方便部署，及時通知，在我對比的cnpm、sinopia、verdaccio、Nexus以後。個人結論是verdaccio，cnpm感受插件有點少貌似，沒有釘釘推送的插件，sinopia都涼了不考慮，Nexus吧不必，我就前端用用而已。verdaccio目前看到還行，繼承了sinopia，插件知足個人需求，安裝簡單，上線小半年沒啥問題，目前有十幾個私有包，連數據庫都不用折騰。路徑切換選擇用nrm便可。

安裝方法

首先我依舊會在本地安裝好，npm install -g verdaccio，配置好config.yaml，裝好釘釘通知，作好目錄屏蔽，而後遷移到個人git中，而後書寫shell腳本。

# build.sh
# /bin/bash
# 啓動私有npm腳本

work_path=$(pwd)
verdaccio --listen 4873 --config ${work_path}"/verdaccio/config.yaml"
複製代碼

而後每次我須要調試配置時，我先在本地測試，push一下，到服務器pull一下，執行pm2 start build.sh或者pm2 restart build。固然這也是能夠加到jekins。

注意

yaml這種配置文件請認真去研究一下怎麼寫，縮進空格有點不一樣。storage/.sinopia-db.json必定要是json格式不能爲空，並且內容能夠是{"list":[],"secret":""}

總結：其實搭建私有npm不難，難在如何設置私有npm包的發佈規則，互相依賴升級等，能夠用lerna來作。私有npm規則，以及lerna的使用，等我稍後總結。

項目模版

每次new cli我不反對，可是真的不累麼，那麼多包要加，有些特有的地方架子還要改。目前我總結出3套，ant-admin-template、nuxt-mobile-template、spa-mobile-template。

實現方法（只以admin例子）

新開目錄，而後執行new cli，生成基礎項目模版。對基礎模版作一些調整，而且安裝一些基礎包

調整的基礎模版

|----- dist/                            正式環境產出
|----- conf/                            配置文件
        |----- alias.js                 公共路徑配置文件
        |----- development.js           開發環境配置文件
        |----- production.js            正式環境配置文件
        |----- oss.js                   build以後將文件上傳到oss
|----- src/                             開發目錄
        |----- components/              公共業務組件
        |----- pages/                   頁面
        |----- hoc/                     HOC
        |----- serverice/               中間層
        |----- utils/                   通用方法
        |----- index.css                主css
        |----- index.js                 主入口文件
        |----- router.js                路由裝載配置
|----- .editorconfig                    統一開發格式配置文件
|----- .eslintrc                        開發格式配置文件
|----- .webpackrc.js                    webpack配置文件
|----- .gitignore                       git提交屏蔽文件
|----- package.json                     npm配置文件
|----- index.ejs                        index.html模版文件

-------------分割線----------------

scr/pages
pages
|----- index.js                                 出口文件
|----- [name]Page                               集成業務代碼
        |----- index.js                         集成頁面view，model，router
        |----- components                       當前業務專屬組件
                |----- index.js                 view層
        |----- [name]                           業務文件夾
                |----- model.js                 model層
                |----- [name]Component.js       當前page專屬組件
複製代碼

可能用到的插件包，可自行刪減

{
  "axios": "^0.18.0",
  "prop-types": "^15.6.1",
  "qs": "^6.7.0",
  "ali-oss": "^6.0.1",
  "underscore": "^1.9.1",
  "husky": "1.1.2",
  "@xxx/xxx": "^x.x.x", // 私有包
}
複製代碼

製做完成，push到git中，若是須要新開管理臺，只要pull，npm i，改改nginx便可。nginx我已經腳本化了，很簡單就能部署。

注意

登錄、退出、鑑權，預留空間出來，由於每一個項目都會有細微差異，讓開發人員自行修改便可。

總結：這種項目模版形式，快速開發新業務線，例如運營管理臺、財務管理臺、等等內部管理臺使用，或者做爲spa骨架，小程序骨架，pc骨架，爲啥要開這麼多管理臺？少年，你，財務系統、erp系統、cms系統、售後系統，真的不要切分開來麼？有精力作權限切分，搞的一個項目臃腫不堪，不如獨立。每一個平臺有本身的帳戶登錄權限。簡單省事，反正都是一套架子，也不存在什麼跨項目。升級的話，基礎目錄即結構不變，升級npm包、升級私有npm包便可。請記住，看上去合併很容易，但複雜度高。分開會加速開發，同時下降複雜度。

服務器初始化

快速在服務器上安裝git、nrm、nvm，固然這個是一次性的，後續我作鏡像便可。固然有些特殊狀況，我也會用到，例如我要製做新的鏡像。直接貼代碼把不解釋了。

安裝git

#!/bin/bash
# 安裝最新git
# 須要exit以後再次進入機器，git命令纔會生效
yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel asciidoc wget
yum install gcc perl-ExtUtils-MakeMaker
yum remove git
cd /usr/local/src/
wget https://www.kernel.org/pub/software/scm/git/git-2.15.1.tar.xz
tar -vxf git-2.15.1.tar.xz
cd git-2.15.1
make prefix=/usr/local/git all
make prefix=/usr/local/git install
echo "export PATH=$PATH:/usr/local/git/bin" >> /etc/profile
source /etc/profile
git --version
複製代碼

安裝nvm

#!/bin/bash
# 安裝nvm做爲node版本控制
# 須要exit以後再次進入機器，nvm命令纔會生效
wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.34.0/install.sh | bash
複製代碼

安裝nrm

#!/bin/bash
# 安裝nrm做爲npm線路控制
npm install -g nrm
nrm ls
複製代碼

注意：先安裝git、nvm，再安裝nrm

總結：拒絕重複勞動，我只須要touch git.sh && vim git.sh，拷貝代碼，執行便可。固然你能夠說製做docker鏡像，目前我還沒研究透徹。公司專業的運維同窗也怪忙的，我只能稍微請教一番，仍是我本身先動手把。

非代碼層面的測試交付

代碼層面，經過mock、eslint、code review、單元測試等手段測試能夠良好把控。前端程序員不少問題都是跨端，不一樣app版本測試所帶來的。這裏我會要求開發人員空出一天或者半天時間，整理業務點，梳理測試的表格。固然也會有，沒有測試到的點，這能夠經過補充慢慢完善。這東西通常會在大促使用、或者是重要功能，重要項目使用。梳理完成以後，我都會要求開發人員以郵件形式抄送給我，我會二次檢查，在項目上線半天前，我會再次要求開發人員以郵件形式抄送給我查看狀況，預留給績效考覈，以及我再次檢查確認是否有遺漏。

例如：

移動端

  • UI兼容測試
    • iphoneX
      • xxx頁面
      • xxx頁面
      • xxx頁面
    • iPhone XS
      • xxx頁面
      • xxx頁面
      • xxx頁面
    • iphone8
      • xxx頁面
      • xxx頁面
      • xxx頁面
    • 小米8
      • xxx頁面
      • xxx頁面
      • xxx頁面
    • 小米7
      • xxx頁面
      • xxx頁面
      • xxx頁面
    • 紅米
      • xxx頁面
      • xxx頁面
      • xxx頁面

andorid版本測試

  • x.x.x

    • 頁面功能點
    • 頁面功能點
    • 頁面功能點
    • 頁面功能點

  • x.x.x

    • 頁面功能點
    • 頁面功能點
    • 頁面功能點
    • 頁面功能點

ios版本測試

  • x.x.x

    • 頁面功能點
    • 頁面功能點
    • 頁面功能點
    • 頁面功能點

  • x.x.x

    • 頁面功能點
    • 頁面功能點
    • 頁面功能點
    • 頁面功能點

微信端測試

  • x.x.x
    • 頁面功能點
    • 頁面功能點
    • 頁面功能點
    • 頁面功能點

pc端

UI兼容測試

  • xx瀏覽器 x.x.x版本
    • xxx頁面
    • xxx頁面
    • xxx頁面
  • xx瀏覽器 x.x.x版本
    • xxx頁面
    • xxx頁面
    • xxx頁面

xx瀏覽器 x.x.x版本功能測試

  • 頁面功能點
  • 頁面功能點
  • 頁面功能點
  • 頁面功能點

xx瀏覽器 x.x.x版本功能測試

  • 頁面功能點
  • 頁面功能點
  • 頁面功能點
  • 頁面功能點

總結：不是有專業的測試人員麼？很差意思，做爲程序員自測都不能經過，還寫啥代碼，還寫啥好代碼。bug是跟績效掛鉤的，就問你要錢嗎？績效漂亮了，每一個季度發錢，大大的給，不爽麼？你出去找工做底氣足嗎？大聲喊出，我有完備的測試流程，我寫的代碼基本0bug，不驕傲麼？

錯誤監控

抓取頁面js異常，上報UA/錯誤提示信息、分析日誌/5xx/4xx、CDN異常監控、設置n min以內5xx，4xx閾值，這些都是基礎運維服務的東西不深刻。關注小程序的開發 > 錯誤查詢/性能監控/告警設置。這一塊我還沒有特別深刻，其實都是阿里雲的服務設置一下，或者天天檢查微信公衆平臺，或者使用第三方監控平臺。有機會詳談。

總結：錯誤監控，大部分都是基於日誌系統的，前端惟一特殊的點就是會有js報錯的狀況，稱之爲崩潰率。反正基於日誌就對了。pv、uv的？？？？喵喵喵

獲取最新信息

請用rss訂閱的方式，訂閱你所使用的開源項目，第一時間獲取，version信息、commit信息、fixbug信息，做爲leader你要時刻掌握最新諮詢，而不是被人告知。

結語

很差意思，洋洋灑灑寫了這麼多，能看到這裏的，也不容易，牛逼了老弟/老哥/老妹/老姐。說老實話，還有不少地方沒說，例如：腳本化小程序發佈、腳本化發佈多個端的小程序、eslint的使用細節、webhook的使用如何禁止merge、githook細節、commit log 規範、打tag包、釘釘的推送、cdn部署、code review的標準、npm包的標準、單元測試的普及、性能監控、api切分、用中間頁鑑權、設備指紋、支付安全、將bs構架快讀切換cs構架、如何保證多個項目同時在測試環境同時交付測試、灰度發佈等等還有不少東西把，這些就等我慢慢體驗了，慢慢整理了。

這些東西爲就不能稱之爲架構，只是我我的的一些逗比操做而已，這套東西3～10人小團隊，20條業務線，給個人感受是能夠撐住的。前提是在業務量在高速增加的狀況下使用。我曾經問過我師傅，爲啥，他在的時候不作，明明他都懂。他回答的是：「公司在什麼階段作什麼事情，當公司在尋找主營業務，不停試錯時，你固化的構架，就不適合這家公司，當公司尋找到這個點以後，你用構架就能快速輔助開發，業務其實沒啥寫的，就看怎麼寫的快，跟上市場，讓公司能快速響應市場，或者引領市場」。好吧，我服氣

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程