前言
程序開發畢竟還不是搬磚這種無腦體力勞動，需要事先有標准，有架構，有設計，絕對不是新公司今天創立，明天就可以開始編碼的。其實很多公司在起步的時候沒有財力和資源建設獨立的基礎架構或平台架構部門，甚至運維團隊都沒有，但是這不妨礙我們心中有一個藍圖知道努力的方向，本文我們就簡單聊聊平台架構相關的工作內容（或者說作為一個技術管理，應該去梳理、統一、明確的部分）的藍圖。由於本文覆蓋的內容比較多，只能拋磚引玉大概提一些，無法一一展開太詳細的東西。圖中的數字是我認為的優先級，僅供參考。
規范
規范它雖然不是一個實際的代碼或組件，只是一個文檔，但是我覺得非常重要。沒有規范，那么員工加下去任何一行新代碼可能都是錯的，整個研發流程也可能會因為沒有規范導致很多不必要的事故產生。
- 代碼提交&分支管理規范，我們可以在gitflow基礎上根據實際情況（結合運維流程，項目復雜度，團隊人數，發布周期）進行細化，涉及到：
- 有哪幾個常駐分支，哪幾個臨時分支？
- 分支命名規范？
- 提交代碼描述規范？
- 分支遷出和合並的時機？
- 哪些分支普通開發沒有權限直接提交？
- 測試用什么分支，上線又用什么分支？
- 多版本並行開發如何提測？
- Hotfix如何處理分支？
- 編碼規范，比如Java代碼可以以阿里Java開發手冊為基礎，大家一起過一遍，針對項目的實際情況（時間要求，對性能要求），選擇其中的一些堅決執行，然后補充一些其它的。我們也可以讓大家的IDE使用（導入）統一的Code Style Template來要求一致的編碼格式。因為Code Style的不一致導致提交的時候大范圍的代碼新增刪除完全會污染提交，讓大家很難看出提交的代碼到底改了什么。
- 數據庫設計規范。阿里Java開發手冊里包含了一小部分數據庫設計規范，術業有專攻，這個還是應該請資深DBA來給出一定的規范，包括但不限於：
- 命名（表和字段前綴后綴命名，外鍵字段命名、通用字段命名統一）規范
- 字段設計類型規范
- 字段冗余規范
- 通用字段規范
- 索引使用規范
- ……。可以參考《朱曄的互聯網架構實踐心得S2E1：業務代碼究竟難不難寫？》中提到的一些內容
- 項目結構規范，對於Java Maven項目來說基本目錄結構比較統一，對於其它語言的項目（比如Python），目錄結構沒有一定標准的話，項目源碼結構會千奇百怪，最好還是對於項目結構有一個規范，包括：
- 三層結構目錄划分
- 多環境（Profile）配置文件
- 服務接口、服務實現、Web、Job模塊命名
- 最后是項目管理流程，有一些公司會有專門的PMO，有一些初創公司研發Leader也會充當PMO的角色，雖然這個活一般和平台架構沒啥關系，不管怎么樣，既然是項目肯定少不了項目管理，作為技術管理角色需要關注的一個點，項目管理流程也是比較重要的：
- 迭代周期，迭代周期中的大環節大概發生的時間點
- 開哪些會，開會時間點是？（日站會、周例會、啟動會、回顧會、復盤會、排期會、PRD預評審會、PRD評審會、測試用例評審會、上線方案討論會）
- 項目生命周期中每一個角色產出哪些文檔？
- 任務在哪里管理，每一個角色怎么去維護任務狀態的流轉？不可能任務的每一個狀態的流轉都由PMO來做
基礎框架
使用一些基礎框架來做應用開發是必須的，對於Java技術棧，大家所熟悉的框架有Spring Cloud全家桶、Spring Boot套件（封裝的各種starters）、Mybatis等，直接使用這些框架進行開發是可以的，但是更建議的是由基礎架構團隊封裝自己的框架，自己做一層封裝，我們可以以類似Spring Boot Starter的模式，為所有的組件封裝自己的Starter模塊，好處是：
- 方便進行統一的外部依賴類庫 & 庫版本管理和約定
- 方便針對公司內部情況做更合適的自動配置（甚至實現0配置）
- 如果內部技術棧是異構的話，使用統一的框架有助於技術棧后端基礎設施的打通
- 為所有的模塊打通監控，自動配置AOP做相應的攔截統一抓取獲取監控數據
- 模塊之間可以相互整合和配合，實現1+1>2的效果
- 還有很重要的一點是，我們可以提供相應的管控后台來配合框架使用，把框架的配置、管理和審計暴露在控制台上
其實說白了，就是使用自己封裝的類庫占坑，哪怕只是一層淺淺的封裝，也是很有好處的，不僅僅是做了各種統一（使用框架的統一，框架版本號的統一），更多的是因為占了坑（當然，要擴展做Java agent動態字節碼注入的方式也是可行的，這種方式的缺點是沒有辦法提供API給業務使用），以后直接可以通過升級框架通過IOC組件替換+AOP直接做各種擴展（不需要再麻煩業務團隊了）。
我們來看看這里腦圖上大概列出的一些業務開發需要用到的常見模塊（可以看一下我們公司開源的框架https://github.com/ke-finance/summerframework ，當然開源出來的模塊比較少，實際內部封裝了這里提到的所有模塊）：
- Web MVC：可以基於Spring MVC進行封裝，增加一些模板引擎的支持等
- 數據訪問：可以基於MyBatis或Mybatis Plus+Druid數據源進行封裝，做一些額外的功能，比如敏感數據加密保存
- RPC服務調用或微服務：可以基於Dubbo或Spring Cloud（Feign+Eureka）進行封裝，在客戶端方面擴展一些更智能的LB算法，以及路由策略（比如灰度）等功能
- Web API：可以在Spring MVC+Swagger UI基礎上實現功能，提供統一的RESTful服務端API的標准，比如規范化API版本、響應結構體自動包裝（自適應）、錯誤包裝、HATEOAS超媒體資源導航整合、數據加解密實現、Collection資源的規范化、自動的mock接口的實現等
- 配置：可以基於攜程Apollo（https://github.com/ctripcorp/apollo ）客戶端進行封裝，做自動配置
- 消息：可以封裝RabbitMQ、RocketMQ的客戶端實現統一的消息API，然后擴展事務消息（收發消息和業務邏輯本地事務在一個事務中處理）等功能
- 緩存：可以基於CacheCloud（https://github.com/sohutv/cachecloud ）提供Redis緩存服務
- 調度：可以封裝XXLJob（https://github.com/xuxueli/xxl-job/ ）或ElasticJob（http://elasticjob.io）提供調度服務
- 日志監控：可以基於Micrometer實現應用打點，找一個APM（Skywalking https://github.com/apache/skywalking 或Pinpoint https://github.com/naver/pinpoint ）整合trace功能，擴展logback做日志脫敏，擴展Spring Boot Actuator Endpoint等功能
- 鎖：可以基於Redisson封裝分布式鎖，使用統一的API來提供內存鎖和分布式鎖
- 分布式事務：主要是兩塊，同步2PC分布式事務處理（比如我們開源的https://github.com/ke-finance/dts ），異步的saga思想的實現，參考https://github.com/eventuate-tram/eventuate-tram-sagas 。
- 彈性：流控+隔離+熔斷，考慮基於https://github.com/alibaba/Sentinel 來實現，可以是獨立的模塊提供服務，也可以整合到Web API或RPC模塊中去
- 安全：可以基於Spring Security進行擴展，加入符合業務需求的風控策略進去
基礎平台
基礎平台（管理平台）需要和基礎框架打配合，框架是開發的時候使用的，平台更多的是開發或運維人員做技術運營時使用的。很多開源框架都已經提供了管理后台，我們需要做的可能只是一些小修改，比如包括：
- 打通公司內部自己的賬號登錄體系和權限體系
- 根據不同的環境（開發、測試、灰度、生產）部署多份管理控制台
- 根據需要看是否需要做多租戶的改造，實現業務隔離
有些平台是重流程的，這些可能需要自主開發，大概介紹一下腦圖上提到的這些：
- 配置平台：如果使用了攜程Apollo，自然就是使用Apollo的管理后台
- 微服務管理平台：這里我列出了兩個方面的工作，一個是服務中心，更多的是服務維護、管理、監控方面的功能，可以基於Spring Cloud Admin進行改造；一個是服務集市，更多的是服務標准化方面的管理，比如服務上線需要的文檔，接入的監控系統，以及上線后統一的文檔中心，服務集市類似於App Store的概念
- 緩存平台，如果使用了CacheCloud，可以使用CacheCloud的管理后台
- 日志平台，分為兩塊，一塊是日志收集展示基本ELK已經是標准；還有一塊是日志異常報警，可以自己來開發，基於Kafka消費日志異步做日志篩選+聚合結合自己公司的IM和郵件體系做報警
- 數據庫管理平台：
- DDL/DML工作流：開發提交申請，主管審批，自動執行，外加自動的風險檢測，優化建議等
- DDL/DML變更通知：方便大數據以及運營團隊針對感興趣的數據庫和表進行訂閱，在DDL應用到各個環境（測試、生產）的時候能夠第一時間得到通知可以進行人工、自動處理（類似before，after Filter的概念）
- 數據庫知識庫：有一個統一的地方查看數據庫的結構說明、字典枚舉的定義
- 當然數據庫管理平台還可以進一步做數據庫監控、慢SQL優化原因分析等功能
- 全鏈路追蹤平台：比如如果使用Skywalking的話可以實現它提供的管理台，主要功能無非是依賴拓撲分析、Trace查看、服務性能分析等
- 指標查看平台：分為兩塊，Dashboard一般可以考慮直接使用Grafana，報警的話雖然Grafana也有Alert但是還是建議在更底層（數據源頭）去做，可以基於流處理去做或基於定時拉的方式去實現
基礎中間件
中間件是指獨立部署的不具有業務邏輯耦合 的通用服務，存儲服務在廣義上歸到中間件也不是不可以，這里大概列了幾個典型：
- MQ代理（Broker，不是Proxy），比如RabbitMQ、RocketMQ、Kafka
- API網關，有很多開源的網關實現，比如Kong（https://github.com/Kong/kong ）、Spring Cloud Gateway，我們也實現了一套https://github.com/ke-finance/tesla ，一般網關的主要功能是調用路由、協議轉換、調用編排，然后也會以插件和過濾器形式提供很多安全、彈性方面的擴展功能
- DB代理，比如類似https://github.com/flike/kingshard 和https://github.com/Qihoo360/Atlas 的MySQL Proxy，實現數據庫的讀寫分離、分表分庫、故障轉移、彈性處理、監控、SQL優化等功能
- ES集群，也可以理解為中間件，畢竟ES其實做的就是基於Lucene的分布式集群管理工作
這些中間件雖然很多時候做的是Proxy背后的其它服務，但是節點本身很可能是有狀態的，也需要考慮中間件本身的高可用性問題。
基礎服務
一般而言如果公司具有多個項目的話，項目之間肯定會用到一些通用的內部和外部能力，這些能力和業務邏輯沒有太多關系，可以考慮把這些能力進行統一的封裝獨立部署以微服務形式提供出來，這樣所有項目都可以快速對接。
在這里把基礎服務分為了兩類，一類是沒有業務邏輯的純基礎服務，往往是對接封裝一個或多個外部服務通道，另外一類是包含一些業務的業務基礎服務。對於第一類基礎服務你可能會想，既然是對接外部服務通道直接使用他們的SDK或服務是不是直接在業務系統使用那些三方SDK就好了，基礎服務是需要做什么呢？我覺得基礎服務應該這么封裝：
- 封裝外部服務的SDK，一般而言比如短信也好、推送也好、存儲也好，都會使用多家提供的服務做備份、降級，通過我們的SDK提供統一的對內API，屏蔽不同SDK的API差異
- 提供一個服務端，在服務端做數據落地，落地的目的有幾個：
- 方便和外部進行服務消費對賬
- 方便出錯的時候查找原因
- 方便和外部服務同步調用狀態（比如短信到達）
- 方便進行服務余額預警
- 服務端除了做數據落地，由統一的服務端做出口的好處是：
- 做權限控制，一般而言即使是公司內部的項目進行基礎服務的調用應該也是需要先申請再使用的，甚至需要做服務調用量的控制（類似在內部再實現一層SaaS）
- 收斂調用源IP
- 集中管理調用外部SaaS服務的密鑰
- 外部服務的降級和切換策略更換比較方便
- 給接入方做報警
- 做一個管理后台，雖然外部服務提供方作為SaaS產品一般都會有不錯的控制台（其實更多的時候，不可能把外部服務的控制台的權限放給所有人看，內部業務方看自己的基礎服務控制台即可），但是我們內部做一個管理后台意義還是很大的，主要的功能一般是：
- 統一登錄
- 賬號（包括Secret）申請和分配，以及配額、限流等配置（管理員權限）
- 調用記錄（請求、結果）查看
- 調用模板的配置（考慮一下是不是放開服務的使用，比如短信、郵件、推送一般是基於模板的，模板需要內部外部審核后才能使用）
如果每一個服務都有控制台的話，可以大大方便業務方的自主接入和問題排查，這是基礎服務封裝非常有價值的一個點，對於大點的公司內部項目眾多就更需要把基礎服務在內部進行SaaS化了，而且最好對於不同的基礎服務打通接入方（統一的地方來申請所有需要的基礎服務）。
這里腦圖上大概列了一些常見的基礎服務和業務服務，每一個公司根據自己的業務一般都會不盡相同，基礎服務包括：
- 短信：接入多個短信渠道，根據政策、費率、到達率等情況路由
- 文件存儲：接入多個小文件存儲服務（比如七牛、騰訊雲），根據存儲服務提供的功能，文件大小、費率等情況路由
- 郵件：接入內部和外部（比如SendCloud）的郵件服務，根據使用場景進行路由
- 推送：接入多個推送渠道（比如極光、個推），並且做用戶、設備的關系維護
- 唯一ID：全局唯一ID的生成
- 圖形、滑動、點擊、智能驗證碼：提供統一的驗證碼服務，可以根據場景自動選擇驗證碼類型
- 電子簽章：接入多個電子簽章服務，根據費率等因素路由
- 地圖服務：接入多個外部地圖服務，根據功能以及接入方使用的地圖進行服務選擇
業務服務包括：
- RBAC權限控制：統一的RBAC配置后台，以及方便的SDK
- 通用表單服務：根據后台配置的表單自動生成界面，以及表單信息的收集
- 狀態機：可以借鑒https://github.com/hekailiang/squirrel ，基於狀態(State)、行為(Action)、轉移(Transition)、條件(Condition)等概念，構建基於數據庫的狀態機平台
- 統一支付：聚合支付，業務方可以快速接入多種支付渠道，並且統一支付可以提供統一的SDK和H5來實現統一的支付收銀台
- 工作流、爬蟲、SSO……不詳細說明了
工程效率
接下去也簡單提一下工程效率和運維范疇的事情，雖然這和平台架構沒啥太大關系，但是這兩塊是很重要的技術基建工作：
- 源代碼倉庫：比如可以選擇Gitlab或atlassian三件套的Bitbucket
- 內部類庫倉庫：比如Java的Maven倉庫，可以自己搭建Nexus倉庫
- 項目管理平台：可以選擇SaaS產品（比如Tower、Teambition），比較有名的是atlassian三件套的Jira
- 知識管理平台：可以選擇SaaS或開源Wiki產品，比較有名的是atlassian三件套的Confluence
- Bug管理平台：比如可以選擇禪道或直接復用Jira
- 代碼質量分析：比如可以搭建SonarQube平台
運維
這里提到的一些運維系統相關工作有的公司是架構團隊來建設的，列一個大概：
- CI/CD平台：一般而言需要自己結合公司的工作流程做一套CI/CD平台（底層可以基於Jenkins（或直接SSH+腳本）封裝），這個平台需要結合公司的工作流程去做，比如誰可以發起流程，每一個發布環節需要誰來審批，發布時間窗口等等
- DNS平台：一般會直接使用域名管理商的平台或類似DNSPod這種平台
- CMDB：一般都會根據自己的情況自建平台，進行運維各個層次相關資源的元數據以及配置管理
- 監控：一般會基於Prometheus+Grafana+Zabbix等開源項目來打造運維的基礎監控
- CDN平台：一般是用雲的，比如七牛、又拍或三大雲服務的CDN都可以
- 集群配置管理：這個不是指CMDB，是指批量進行集群配置應用操作，管理操作的平台，比如Chef、Puppet、Ansible、Fabric，一般也是基於開源改造封裝或直接用開源的
- 容器編排：比如K8S平台，一般可能會基於k8s的API做一套自己的k8s管控平台或選用類似Rancher這種更好用更高層的服務，完全基於命令行的k8s運維不是很高效易用
- 容器鏡像倉庫：比如Docker私有倉庫Harbor
總結
好吧，的確一些中大型互聯網公司是有超過100個內部系統是和研發相關的，甚至需要有專門的導航網站來管理工程效率、運維、基礎框架、基礎服務、基礎中間件、基礎平台的這些網站，這些系統本身的維護工作量也是不小的，一整理就會發現原來除了業務程序還有這么多周邊的東西是為研發服務的，歡迎大家針對本文的內容進行補充。