正好這段時間咱們在封閉研發咱們的新一代數字化雲平臺（theplatform），藉此機會和你們分享一下咱們的整體設計及思路：
sql
theplatform是一款基於微服務架構的DevOps容器雲平臺，設計主體分紅了三個步驟：
1. 看問題：企業IT運營中的常見問題有哪些
2. 找方法：應對上述問題，常規手段有哪些
3. 作設計：這是今天的重點，導出概念模型、全景圖、技術棧、工做分工、4視圖等
其實對「看問題」和「找方法」咱們同事都有過詳細描述，這裏咱們先簡單回顧一下
企業通常有信息流和業務流兩段，尤爲在業務流中，從需求到最終運營的各環節中，每一個環節都有趨於完善的方法和要解決的實際問題
好比：設計階段，設計老是在紙面，真實開發時並不徹底依據，或者只有詳細設計，缺乏優秀理念支撐
再好比：運營階段，隨着系統的增長，故障定位愈來愈困難，故障處理方法和積累的知識傳遞性不佳，對後續的產品發展指導性不強
數字化運營一樣面臨着諸多挑戰
好比：業務語言和技術語言失真傳遞
再好比：因技術緣由致使的技術欠債致使包袱愈來愈重
再好比：因重複勞動、我的注意的一些問題，團隊分工不合理，價值感不強等，致使人員變動影響巨大，同時束縛了知識工做者的創造力
那咱們看看有些什麼解決方法呢？
最簡單的，咱們遇到問題解決問題（被動的作法），將問題逐個擊破
好比：對於關鍵事情依賴人的問題，咱們可讓機器來作相關的事情，解放生產力
再好比：對於技術債務積壓的問題，能夠經過找合適的人，優秀的組織分工等慢慢改進
還能想到些什麼方法或名詞或理念？
還有不少頗有針對性的方法，好比敏捷，扁平組織，PDCA質量環
那咱們選擇了DevOps這條路，來實現咱們理想的運營，同時以微服務架構爲核心，協做與治理相結合，打造廣義的DevOps
接下來就是咱們如何作設計了，我作設計的方法通常是從兩個視角出發
平臺視角很好理解，看全景，那人的視角是什麼：
記得有位大拿說過，架構師必須有人員安排的權利，若是你不清楚團隊的人的特色，或者無法調動最合適的資源，即便設計再牛的架構，也未必落得了地。
那咱們先看看如何推演第一個視角關心的全景圖：
咱們分了三個比較重要的工做：
1. 場景拆分，用場景流程來發現須要改進的問題，而後用自助或自動的方式來解決問題，同時把這些解決方法劃分到各領域系統，造成平臺的支撐，這裏場景拆的不少，有些草圖，各位可簡單瀏覽，就不用細看了，都是以前的初稿：
2. First app，或者你們習慣叫原型應用，這個實際上是很是重要的一環，咱們正是經過原型應用開發來驗證場景，同時將咱們從設計到運營概括成了初版：23步完成，最終版：9步完成，具體步驟之後會有同窗分享
3. 源圖宣講，咱們提早小範圍，大範圍宣講了不止30次，一是爲了你們有統一的思想和理解，二是爲了經過你們的驗證反饋來優化咱們的源圖
最終咱們導出了這張全景圖：
這張圖把DevOps工做者須要的服務能力（包括服務接入能力）、自動化處理能力、運營看板、遙測優化等作了定義，最終但願造成一個有機的devops總體，固然，還要涵蓋咱們以前的拆分場景，體現咱們firstapp中的步驟等
那咱們再看看如何推演第二個視角關心的組織架構工做的
一樣是三點：
1. 基於全景圖羅列技術，獲得須要預研或對比的技術列表
2. 對人員能力進行劃分，造成團隊，要注意團隊成員的互補性，這個前兩天有同事已經介紹過了
3. 領域系統分層，將以前導出的各領域系統分類，讓團隊領取各系統，最終結合系統分層，造成有層次（上下游）的團隊
最終結果是這樣的：
這張圖其實把團隊分工、支撐領域系統和組件、須要掌握和使用的技術棧作了分解，結合這張圖，後續咱們會有同窗來分享各個領域系統的設計和具體技術棧，這裏我就不贅述了
那有了團隊，有了全景圖，咱們接着作啥呢？
咱們能夠回到傳統設計，概念模型，4+1視圖，確實咱們也是這麼作的
這圖其實花了咱們最長時間來定稿，這裏面概念看似簡單，其實不少：
好比：部署包=介質包+配置，這和傳統的CI和CD體系就有點不同
再好比：環境分開發、測試、預發、生產，咱們以爲即便公有云上，也應該給客戶將這些作物理或邏輯隔離，由於你們的配額需求不同，容器replication需求也可能不同
再好比：運維反饋，既然要作devops，那整個過程導出都應該能夠有檢查點插入，爲運營提供有效數據，咱們把檢查點至少分紅了四類，包括過程的、安全的、性能的、業務的
有人說，整體設計期間，各小團隊的工做有點難以開展，咱們除了培訓外，同步，咱們的各團隊已經開始了技術預研工做
這些工做實際上是須要結合各團隊預研成果，補充進整體設計的
咱們前面提到了導出領域系統，我一直沒講有哪些，這裏給出一個完整的：
上面部分是核心的，你們能夠仔細看下，每一個系統都解決的是一個領域的問題：
好比：軟件產品的管理，軟件各階段環境的管理，質量的管理，部署包、二進制包的管理，資源管理，監控中心，認證中心等
下面部分是完整的，按能力分層的，經過這個其實咱們就能夠出邏輯架構圖了
圖上分了：
基礎設施層：包括IaaS，CaaS，咱們分別是基於Openstack和Kubernetes的，上層有一層不一樣環境的適配
基礎服務層：包括服務管理與調度的基礎能力，如註冊中心，編排，伸縮漂移。還有一堆具體的企業級或互聯網式的雲服務
DevOps層：更多的是工做流程的串接，看板等文化的體現
再接着是部署視圖（或者叫物理視圖），咱們的公有云是要部署在阿里雲上的（固然遇到了很多坑，後面有機會能夠再分享，片子已經準備好了，呵呵）
圖上最上面一層是用戶的微應用，下層是咱們的管理節點，固然配置不同都是有所考慮的
再接着是運行視圖（或者叫進程視圖），這個比較簡單寫，咱們自己是分佈式的管理，經過統一的門戶來提供入口（只有門戶和兩個須要開放的進程放到DMZ）
運行過程統一了rest的資源風格，咱們全部的節點都是跑在容器中（本身開發本身吧）
再接着就是開發視圖了
圖上有兩個典型項目：
一個是對外的能力包，定義了API，SPI
另外一個實際上是具體實現包，script是啓停的鉤子腳本，sql是數據庫相關（包括回滾）
這裏圖上的例子是說，在咱們的模型中，若是A產品依賴B產品，那麼咱們須要引入Adapter這個概念，A自己對外提供API能力，A的SPI須要B實現，但可能B已經有本身的API能力了，那中間Adapter實際上是作了SPI與API的適配（這塊概念也不少，後面也會有同窗詳細講，咱們分佈式設計的開發設計）
固然，咱們還作了其餘的一些關鍵設計，包括：
像灰度發佈，多租戶這些，還有咱們的邀請客戶（邀請碼，邀請方式）的設計（這個會涉及到資源預置等方面，你們都懂的）
還有MVP，由於設計的不少，咱們第一個版本只有很短的週期，必需要有取捨，又要體現咱們的理念
差很少初步設計就這樣了，但願各位給出好建議！