架構標准化影響着后續一系列效率和穩定性平台的建設方案。
架構標准化是架構、開發和運維共同的職責。
常見的分布式基礎架構組件
微服務的分布式架構下，涉及到的主要基礎架構組件
- 分布式服務化框架，業界開源產品比如 Dubbo、Spring Cloud 這樣的框架；
- 分布式緩存及框架，業界如 Redis、Memcached，框架如 Codis 和 Redis Cluster；
- 數據庫及分布式數據庫框架，這兩者是密不可分的，數據庫如 MySQL、MariaDB 等，中間件如淘寶 TDDL（現在叫 DRDS）、Sharding-JDBC 等。當前非常火熱的 TiDB，就直接實現了分布式數據庫的功能，不再額外選擇中間件框架；
- 分布式的消息中間件，業界如 Kafka、RabbitMQ、ActiveMQ 以及 RocketMQ 等；
- 前端接入層部分，如四層負載 LVS，七層負載 Nginx 或 Apache，再比如硬件負載 F5 等。
基礎架構組件的選型問題
是自研還是選擇開源產品？有這么多的開源產品到底該選哪一個？
按正常的思路，一定是先組織選型調研，然后進行方案驗證和對比，最后確認統一的解決方案。
我們以分布式服務化框架為例，我之前遇到的一個實際情況就是，整個大的技術團隊選型時以 Java 技術棧為主。
如果技術選型不一致會出現很多問題。
所以，這個時候我們需要做的，就是對基礎架構有統一的規划和建設。原則上，每種基礎組件只允許一種選型，至少就能滿足 90% 甚至更多的應用場景。
比如數據庫就只允許使用 MySQL，然后版本統一，同時配套的中間件也必須統一，其它的關系型數據庫沒有特殊情況堅決不允許使用，如果遇到特殊情況具體分析。
基礎架構的服務化
對基礎架構組件做了統一標准后，下一步要做的就是服務化
這里以 Redis 緩存為例。
- 創建和容量申請；
- 容量的擴容和縮容，新增分片的服務發現及訪問路由配置；
- 運行指標監控，如 QPS、TPS、存儲數據數量等等；
- 主備切換能力等等。
以上這些，假設都依賴 Redis 提供的原生能力來做，基本是不可維護的。所以必須要基於這些原生能力進行封裝，結合運維場景，將能力服務化，這樣就大大提升了使用方的便利性。
個服務化的過程其實就是 PaaS 化的過程。換言之，如果我們能把基礎架構組件服務化完成，我們的 PaaS 平台也就基本成型了。
運維的職責是什么？
可以歸納為兩步：第一步是基礎架構標准化，第二步是基礎架構服務化。
這個時候，運維必須要有意識去做的兩件事情。
1.參與制定基礎架構標准，並強勢地約束。在這里運維作為線上穩定的 Owner，發揮約束作用有可能會比業務架構師這樣的角色更為有效。另外，由於歷史原因或其他種種因素造成的已有架構標准不統一的問題，是需要開發和運維共同合作去改造的。這里面如何保持良好的協作，制定統一的路線圖也是非常重要的。所以這里強制約束是一方面，同時也要提供工具化的手段來支持開發的改造，也就是下面這個動作。
2.基礎架構的服務化平台開發，目標是平台自助化，讓開發依賴平台的能力自助完成對基礎組件的需求，而不是依賴運維的人。這個事情是驅動運維轉型和改進的動力，也是運維能夠深入了解架構組件細節的有效途徑。同時，要注意到，如果不朝着服務化方向發展，運維將始終被拖累在這些基礎組件的運維操作上。
總結：
基礎架構標准化是影響着后續一系列效率和穩定性平台的建設方案。
對基礎架構有統一的規划和建設。原則上，每種基礎組件只允許一種選型，至少就能滿足 90% 甚至更多的應用場景。
基礎架構的服務化，基於redis等等這些組件對原生能力進行封裝，結合運維場景，將能力服務化，這樣就大大提升了使用方的便利性。基礎架構組件服務化完成，我們的 PaaS 平台也就基本成型了。
運維的職責是：第一步是基礎架構標准化，第二步是基礎架構服務化。
1.參與制定基礎架構標准
2.基礎架構的服務化平台開發，目標是平台自助化，讓開發依賴平台的能力自助完成對基礎組件的需求，而不是依賴運維的人。