微服務實踐目錄，可以參見連接。
公司構建大中臺之后的事情。
背景：
在作者的0.微服務方法論-1.微服務落地事項、04.軟件產品公司競爭力、05.為什么公司都在提大中臺？等文章中提到了很多關于公司怎樣認識、理解與微服務微服務。在人的認知是需要過程的不可能一次就對一項事物深入的理解。所以，對于微服務中不只有前面的優(yōu)點、可行性等方面。它其實是對人的認知的一種挑戰(zhàn)。
微服務是一種持續(xù)演進的模式。--演進式架構
微服務是一直在變化的。這也是微服務的一大特點，可以為業(yè)務提供很強的創(chuàng)新能力。那微服務具體會像那個方向變化？變化過程中會遇到怎樣的問題？接下來我們就討論這部分內容。
變化：
在學物理的時候，都會對運動有一種基本認識：運動是絕對的，靜止是相對的。在軟件行業(yè)也需要有這種方式，例如：需求有專門管理需求變更的方法、軟件過程管理在不斷的發(fā)展、技術在不斷的升級等等。相對于前面的變化來說，對于一個互聯(lián)網(wǎng)產品公司所關注的業(yè)務形態(tài)、盈利模式、客戶特征、運營指標等等。
對于互聯(lián)網(wǎng)產品公司的怎樣快速滿足業(yè)務形態(tài)變化，適應盈利模式的疊加，適應各種類型的客戶特征就成為重中之重。那對于需求，過程，技術，運維需要做才能適應這種高度不確定的辦法。
在VUCA時代，指導我們在這個時代的做事方式。需要全局性，前瞻性的思維模式考慮怎樣適應多變的世界。微服務就是能夠更好的適應多變的情況。下面以構建、變化、適應的方式說明適應方式。
-
構建
構建過程是產品最開始構建基礎設施的過程。這個時候會做大量的分析、設計工作、管理規(guī)范等等。以這些思考，規(guī)范等內容指導之后的產品過程。所以就顯得這個過程很重要。這個過程為之后奠定產品發(fā)展的基礎，這里針對需求管理，過程管理，技術選型等的思考可能會影響整個公司聲明周期。
在這樣的前提下公司起步階段是非常重要的一個階段，需要公司管理者有能力制定各種規(guī)范與抉擇。針對于其他方面的管理工作會在之后的文章中進行討論。這里我們討論技術方面的內容：
| 編號 | 具體規(guī)范 | 內容 | 說明 |
|---|---|---|---|
| 1 | 工程規(guī)范 | 1.項目規(guī)范，項目中代碼管理、配置管理、編譯方法 2.測試規(guī)范，故障率規(guī)范、自動化測試規(guī)范 3.UI設計規(guī)范，規(guī)范色調、操作設計、布局規(guī)范等 |
主要是管理產品過程的 |
| 2 | 實施規(guī)范 | 1.技術選型規(guī)范 2.工作量評估規(guī)范 |
統(tǒng)一技術，管理公司內部的技術技術棧 |
| 3 | 運維規(guī)范 | 1.容量規(guī)劃 2.安全規(guī)劃 3.部署規(guī)劃 4.升級方法 5.可用性規(guī)劃等 |
規(guī)范運維，避免運維不穩(wěn)定性 |
| 4 | 運營規(guī)范 | 1.指標規(guī)范 2.規(guī)范分析方法 |
規(guī)范化產品運營過程 |
技術規(guī)范
技術方面的選型影響者之后系統(tǒng)的可擴展性，伸縮性，可用性等內容。所以，現(xiàn)在大部分公司在開始構建自己的系統(tǒng)的時候都會直接考慮微服務模式，并配合各種架構模式構建。技術選型方面就參照現(xiàn)在流行的幾個技術棧就好。整體技術規(guī)劃有了，技術選型也有了之后最大的問題就在于工程規(guī)范方面。-
工程規(guī)范
工程規(guī)范方面的一個問題在于怎樣規(guī)劃產品整體。以怎樣的微服務的劃分規(guī)則？怎樣規(guī)劃產品的核心服務層？第三方接入規(guī)范？等等都是需要考慮的內容。其實大中臺已經(jīng)為我們提供了很多思路。而這里要討論的更多的是第三方的定義和第三方的技術規(guī)范。怎么定義第三方？所有除核心系統(tǒng)之外的系統(tǒng)都是第三方？還是只有外部的系統(tǒng)需要接入時才叫第三方？跟第三方之間的技術規(guī)范，行為規(guī)范怎么定義？
這里可以先把問題留在這里，我們以逐步推進的方式解決這幾個問題。
-
變化
隨著業(yè)務的發(fā)展和人們對行業(yè)、對業(yè)務的認識的逐漸深入，人們會對業(yè)務進行重新設計與重新規(guī)劃。這是一種內部產生變化的需求。還有一種是外部產生變更的情況，外部認為對接公司產品有意義，值得付出時會進行第三方對接。
針對第一種變化，如果是業(yè)務形態(tài)發(fā)生了變化，那么接受業(yè)務的變更到核心服務群中即可。針對內部需求變化還有另外一種比較難處理的。就是在業(yè)務逐漸的發(fā)展之后，原先業(yè)務穩(wěn)定發(fā)展，并能持續(xù)進入盈利。現(xiàn)在需要發(fā)展出新的業(yè)務增長點以支撐公司盈利的持續(xù)增長。這個時候就需要構建新的系統(tǒng)。
那如果是發(fā)展出新的業(yè)務，新的業(yè)務的技術微服務怎樣管理？直接加入的系統(tǒng)基礎服務中？另起系統(tǒng)重新管理？這里就帶來了變化。這里也把問題遺留下來，下面一起解決。
-
適應
上面提到了幾個問題：
- 怎么定義第三方？
- 與第三方之間的技術對接怎樣完成？第三方接口的行為規(guī)范怎么定義？
- 新業(yè)務的微服務要加到核心服務群中嗎？
適應就是為了在系統(tǒng)遇到各種各樣的問題時，怎樣讓系統(tǒng)適配這些情況。這些處理策略就是我們的工程規(guī)范。這里闡述幾個觀點，說明作者對于這幾個問題的基本思考：
- 核心微服務系統(tǒng)群必須是穩(wěn)定，有完整的運維規(guī)范，優(yōu)化規(guī)范。
- 核心微服務系統(tǒng)群只提供基本功能。不提供與業(yè)務有任何關系的服務。
- 核心微服務系統(tǒng)群必須能夠支持業(yè)務的不斷擴展。必須提供相關的服務接口或SDK等。
- 核心微服務系統(tǒng)群應是獨立管理與部署的。核心微服務不受外部系統(tǒng)的干擾。
上面提到的核心微服務系統(tǒng)群的概念，可以參加大中臺的概念。但是它是更傾向于穩(wěn)定，通用性的業(yè)務。它是經(jīng)過高度抽象并提供原子操作的核心系統(tǒng)，就像微內核系統(tǒng)中內核。外部的所有內容都是以插件的形式插入到系統(tǒng)中。
在本系列前面的一篇文章【0.微服務方法論-1.微服務落地事項】中大概整理了公司構建微服務時需要考慮的內容。也需要考慮核心微服務群的持續(xù)改進過程。所以，核心微服務既需要滿足不斷擴展的需要，又要滿足穩(wěn)定可靠的要求。那怎么滿足即變化又穩(wěn)定的要求呢？解決上面提到的三個問題就可以解決這個問題。
怎么定義第三方？
在核心服務群外的平臺、系統(tǒng)、服務都是第三方系統(tǒng)。這樣其他系統(tǒng)的建設不會影響核心微服務群?？梢员ＷC核心微服務群的穩(wěn)定。與第三方之間的技術對接怎樣完成？第三方接口的行為規(guī)范怎么定義？
第三方的技術對接使用對外接口管理。不允許使用服務群內部的RPC調用，服務發(fā)現(xiàn)，服務注冊，服務監(jiān)控等的系統(tǒng)。這里可以保證運維時是一個獨立的系統(tǒng)。也可以進行支撐擴展。新業(yè)務的微服務要加到核心服務群中嗎？
新業(yè)務的初始加入需要滿足業(yè)務驗證，業(yè)務驗證之后才考慮是否需要加入核心服務群?？紤]是否需要加入核心服務群，怎樣抽象服務這些在之后的文章中進行說明。
-
持續(xù)改進
不管在生活、學習、工作中都需要持續(xù)的改進，持續(xù)的深入認識某一件事物。就像上面所說的新業(yè)務需要不斷的加入，原先業(yè)務需要不斷的優(yōu)化。所以需要持續(xù)改進的過程。這里的持續(xù)改進就需要持續(xù)的業(yè)務運營數(shù)據(jù)反饋與持續(xù)的添加系統(tǒng)。這個也可以在之后的文章中說明。
總結：
在建設完成微服務群之后，需要考慮之后的很多事情。這里說明的持續(xù)改進只不過是其中的一小部分。我們可以從不同的角度進行考慮以更好的指導之后的技術工作。
