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