導語
今日剛好入職國內某互聯網金融公司W（後臺開發崗）滿一個月，趁此機會總結和分享下入職後的一些感慨。順便與老東家互聯網Y公司從工程技術方面進行對比，從個人角度上看互金與互聯網公司之間的細微差異。
職能角色
每一次版本迭代，都需要不同的角色參與協作完成。從職能角色中可以看出W公司還有業務運維崗，與開發、測試三者構成目前流行的devOps工作模式，三個角色對於業務應用服務都非常清楚。一般跨系統的複雜調用的數據表都是由SA先統一設計，再有開發同學代碼化。開發、測試、運維對於需求文檔、各系統功能、工程日誌、存儲表設計都有一定了解。
| 角色 | 發佈權限 | 架構設計 | 故障處理人 | |
|---|---|---|---|---|
| Y | 產品、開發、pm、測試 | 開發統籌所有環境 | 團隊/項目開發負責人 | 一線運維情況下運維通知開發，普通情況下開發收到告警直接處理 |
| W | 業務、SA、開發、測試、運維 | 開發只限測試環境，運維負責生產環境 | SA統一管理，AB大會評審子系統功能 | 一般由運維負責直接處理生產事故，確實解決不了再通知開發協助解決 |
生產工程
W公司的底層和中間件開發基本採用java語言，大部分情況下只提供java的sdk，全司統一採用。每個新系統的搭建要經過AB大會審批通過，減少關門造輪子，由公司中間件平臺小組專門開發。新功能開發，W公司的新接口開發需要經過嚴格的審批流程，需要負責人提前羅列好全局接口，從安全性看可以統一監控對外接口，但從互聯網的敏捷迭代上看，經常會拖後腿。對於產品測試，W公司會更加註重代碼質量，分別從代碼覆蓋率、報文測試、腳本測試等對應用全方面體檢。產品上線，在開發的協助下，由運維同學在全司統一發布的實驗室執行發佈（每次進出實驗室需要申請通信證）
| 後端語言 | 工程搭建 | 新增接口 | 代碼協同 | 開發環境 | 測試 | 流程管理 | 平臺集成管理 | |
|---|---|---|---|---|---|---|---|---|
| Y | java/c++ | demo工程 | 後端同學負責設計，書寫接口文檔並手動上傳到接口平臺 | svn/git，功能微服務化，大部分只有master和test分支 | 開發辦公一體化，本地機器 | 黑盒測試，默認一套測試環境，需要依託其他平臺劃分 | 各階段各自維護，產品文檔由svn提供，開發文檔由接口文檔平臺管理、測試用例google或者騰訊文檔，測試bug記錄bug系統 | 在dbms申請消息中間件、db、緩存，使用的服務治理中心，配置中心等在工程內部集成，開發撰寫文檔 |
| W | java主流 | 應用腳手架 | 模塊負責人設計並提交新接口申請審批，利用構建工具自動生成接口文檔並上傳到文檔平臺 | git，應用git flow規範 | 遠程桌面，開發隔離公網 | 白盒+黑盒，全司統一規定環境種類，在聯調測試階段約定哪一套環境，各個環境相互隔離。測試環境提供日誌自動上傳功能，可通過設備號讓開發定位上下文與問題 | 統一dpms管理，從產品文檔到開發計劃、開發文檔、開發人力、測試用例、發佈計劃、時間節點 | 所有信息統一在dbms上，可以跟蹤到每個系統下所有的資源 |
技術要點
| 持續集成ci | RPC調用與服務治理 | 鏈路追蹤 | 技術分享平臺 | 服務器登錄腳本 | 擋板服務 | 事務 | |
|---|---|---|---|---|---|---|---|
| Y | 部分項目支持ci和cd | 多個服務治理平臺，當其他服務不支持使用的服務治理平臺時需要手工維護。rpc種類繁多，包括thrift、http、公司自定義二進制協議、hession等 | 使用traceId，由平臺統一生產，落地到各個階段的日誌當中 | 專門講師ppt，高大上的技術分享 | 記錄每個項目所在的服務器地址go | 開發在單元測試中執行mock | 互聯網產品，很少事務操作，nosql成主要存儲方案 |
| W | 支持ci | 統一服務治理平臺，所有rpc統一協議，rpc調用使用全司內部消息總線，原理使用消息中間件（基於rocketMQ定製，支持rr、異步、多播、廣播） | 分爲業務流水號和系統流水號，測試報告必須攜帶流水號 | km文章平臺，每個人都會書寫，可以是開源項目，也可以是工作小總結，形成內部技術搜索引擎 | 登錄交互式腳本，根據項目名和環境類型，以交互形式選擇登錄 | 部門內部統一的擋板服務，可在測試環境中使用，擋板中臺如同postman一般可以記錄每個接口的擋板詳情和重複使用 | 內部自研分佈式mysql，強事務操作，多補償機制 |
總結
兩個公司都有各自的優缺點，Y公司典型的互聯網化，小步快跑，敏捷迭代。W公司由於金融背景，流程嚴格且週期長，角色分工細化監督，安全性可用性高。