微服務(wù)實踐目錄，可以參見連接。

項目對接

公司構(gòu)建大中臺之后的事情,。

背景：

在作者的0.微服務(wù)方法論-1.微服務(wù)落地事項,、04.軟件產(chǎn)品公司競爭力、05.為什么公司都在提大中臺,？等文章中提到了很多關(guān)于公司怎樣認識,、理解與微服務(wù)微服務(wù)。在人的認知是需要過程的不可能一次就對一項事物深入的理解,。所以,，對于微服務(wù)中不只有前面的優(yōu)點、可行性等方面,。它其實是對人的認知的一種挑戰(zhàn),。

微服務(wù)是一種持續(xù)演進的模式。--演進式架構(gòu)

微服務(wù)是一直在變化的,。這也是微服務(wù)的一大特點,，可以為業(yè)務(wù)提供很強的創(chuàng)新能力。那微服務(wù)具體會像那個方向變化,？變化過程中會遇到怎樣的問題,？接下來我們就討論這部分內(nèi)容。

變化：

在學(xué)物理的時候,，都會對運動有一種基本認識：運動是絕對的,，靜止是相對的。在軟件行業(yè)也需要有這種方式,，例如：需求有專門管理需求變更的方法,、軟件過程管理在不斷的發(fā)展、技術(shù)在不斷的升級等等,。相對于前面的變化來說,，對于一個互聯(lián)網(wǎng)產(chǎn)品公司所關(guān)注的業(yè)務(wù)形態(tài)、盈利模式,、客戶特征,、運營指標等等。

對于互聯(lián)網(wǎng)產(chǎn)品公司的怎樣快速滿足業(yè)務(wù)形態(tài)變化,，適應(yīng)盈利模式的疊加,，適應(yīng)各種類型的客戶特征就成為重中之重。那對于需求,，過程,，技術(shù)，運維需要做才能適應(yīng)這種高度不確定的辦法,。

VUCA

在VUCA時代,，指導(dǎo)我們在這個時代的做事方式,。需要全局性，前瞻性的思維模式考慮怎樣適應(yīng)多變的世界,。微服務(wù)就是能夠更好的適應(yīng)多變的情況,。下面以構(gòu)建、變化,、適應(yīng)的方式說明適應(yīng)方式,。

• 構(gòu)建

構(gòu)建過程是產(chǎn)品最開始構(gòu)建基礎(chǔ)設(shè)施的過程。這個時候會做大量的分析,、設(shè)計工作,、管理規(guī)范等等。以這些思考,，規(guī)范等內(nèi)容指導(dǎo)之后的產(chǎn)品過程,。所以就顯得這個過程很重要。這個過程為之后奠定產(chǎn)品發(fā)展的基礎(chǔ),，這里針對需求管理,，過程管理，技術(shù)選型等的思考可能會影響整個公司聲明周期,。

在這樣的前提下公司起步階段是非常重要的一個階段,，需要公司管理者有能力制定各種規(guī)范與抉擇。針對于其他方面的管理工作會在之后的文章中進行討論,。這里我們討論技術(shù)方面的內(nèi)容：

• 技術(shù)規(guī)范
  技術(shù)方面的選型影響者之后系統(tǒng)的可擴展性，伸縮性,，可用性等內(nèi)容,。所以,，現(xiàn)在大部分公司在開始構(gòu)建自己的系統(tǒng)的時候都會直接考慮微服務(wù)模式,，并配合各種架構(gòu)模式構(gòu)建。技術(shù)選型方面就參照現(xiàn)在流行的幾個技術(shù)棧就好,。整體技術(shù)規(guī)劃有了,，技術(shù)選型也有了之后最大的問題就在于工程規(guī)范方面。

• 工程規(guī)范
  工程規(guī)范方面的一個問題在于怎樣規(guī)劃產(chǎn)品整體。以怎樣的微服務(wù)的劃分規(guī)則,？怎樣規(guī)劃產(chǎn)品的核心服務(wù)層,？第三方接入規(guī)范？等等都是需要考慮的內(nèi)容,。其實大中臺已經(jīng)為我們提供了很多思路,。而這里要討論的更多的是第三方的定義和第三方的技術(shù)規(guī)范。

  怎么定義第三方,？所有除核心系統(tǒng)之外的系統(tǒng)都是第三方,？還是只有外部的系統(tǒng)需要接入時才叫第三方？跟第三方之間的技術(shù)規(guī)范,，行為規(guī)范怎么定義,？

  這里可以先把問題留在這里，我們以逐步推進的方式解決這幾個問題,。

• 變化

隨著業(yè)務(wù)的發(fā)展和人們對行業(yè),、對業(yè)務(wù)的認識的逐漸深入，人們會對業(yè)務(wù)進行重新設(shè)計與重新規(guī)劃,。這是一種內(nèi)部產(chǎn)生變化的需求,。還有一種是外部產(chǎn)生變更的情況，外部認為對接公司產(chǎn)品有意義,，值得付出時會進行第三方對接,。

針對第一種變化，如果是業(yè)務(wù)形態(tài)發(fā)生了變化,，那么接受業(yè)務(wù)的變更到核心服務(wù)群中即可,。針對內(nèi)部需求變化還有另外一種比較難處理的。就是在業(yè)務(wù)逐漸的發(fā)展之后,，原先業(yè)務(wù)穩(wěn)定發(fā)展,，并能持續(xù)進入盈利。現(xiàn)在需要發(fā)展出新的業(yè)務(wù)增長點以支撐公司盈利的持續(xù)增長,。這個時候就需要構(gòu)建新的系統(tǒng),。

那如果是發(fā)展出新的業(yè)務(wù)，新的業(yè)務(wù)的技術(shù)微服務(wù)怎樣管理,？直接加入的系統(tǒng)基礎(chǔ)服務(wù)中,？另起系統(tǒng)重新管理？這里就帶來了變化,。這里也把問題遺留下來,，下面一起解決。

• 適應(yīng)

上面提到了幾個問題：

1. 怎么定義第三方,？
2. 與第三方之間的技術(shù)對接怎樣完成,？第三方接口的行為規(guī)范怎么定義,？
3. 新業(yè)務(wù)的微服務(wù)要加到核心服務(wù)群中嗎？

適應(yīng)就是為了在系統(tǒng)遇到各種各樣的問題時,，怎樣讓系統(tǒng)適配這些情況,。這些處理策略就是我們的工程規(guī)范。這里闡述幾個觀點,，說明作者對于這幾個問題的基本思考：

1. 核心微服務(wù)系統(tǒng)群必須是穩(wěn)定,，有完整的運維規(guī)范，優(yōu)化規(guī)范,。
2. 核心微服務(wù)系統(tǒng)群只提供基本功能,。不提供與業(yè)務(wù)有任何關(guān)系的服務(wù)。
3. 核心微服務(wù)系統(tǒng)群必須能夠支持業(yè)務(wù)的不斷擴展,。必須提供相關(guān)的服務(wù)接口或SDK等,。
4. 核心微服務(wù)系統(tǒng)群應(yīng)是獨立管理與部署的。核心微服務(wù)不受外部系統(tǒng)的干擾,。

上面提到的核心微服務(wù)系統(tǒng)群的概念,，可以參加大中臺的概念。但是它是更傾向于穩(wěn)定,，通用性的業(yè)務(wù),。它是經(jīng)過高度抽象并提供原子操作的核心系統(tǒng)，就像微內(nèi)核系統(tǒng)中內(nèi)核,。外部的所有內(nèi)容都是以插件的形式插入到系統(tǒng)中,。

在本系列前面的一篇文章【0.微服務(wù)方法論-1.微服務(wù)落地事項】中大概整理了公司構(gòu)建微服務(wù)時需要考慮的內(nèi)容。也需要考慮核心微服務(wù)群的持續(xù)改進過程,。所以,，核心微服務(wù)既需要滿足不斷擴展的需要，又要滿足穩(wěn)定可靠的要求,。那怎么滿足即變化又穩(wěn)定的要求呢,？解決上面提到的三個問題就可以解決這個問題。

1. 怎么定義第三方,？
   在核心服務(wù)群外的平臺,、系統(tǒng)、服務(wù)都是第三方系統(tǒng),。這樣其他系統(tǒng)的建設(shè)不會影響核心微服務(wù)群,。可以保證核心微服務(wù)群的穩(wěn)定,。

2. 與第三方之間的技術(shù)對接怎樣完成,？第三方接口的行為規(guī)范怎么定義？
   第三方的技術(shù)對接使用對外接口管理,。不允許使用服務(wù)群內(nèi)部的RPC調(diào)用,，服務(wù)發(fā)現(xiàn)，服務(wù)注冊,，服務(wù)監(jiān)控等的系統(tǒng),。這里可以保證運維時是一個獨立的系統(tǒng)。也可以進行支撐擴展,。

3. 新業(yè)務(wù)的微服務(wù)要加到核心服務(wù)群中嗎,？
   新業(yè)務(wù)的初始加入需要滿足業(yè)務(wù)驗證，業(yè)務(wù)驗證之后才考慮是否需要加入核心服務(wù)群,?？紤]是否需要加入核心服務(wù)群，怎樣抽象服務(wù)這些在之后的文章中進行說明,。

• 持續(xù)改進

不管在生活,、學(xué)習(xí)、工作中都需要持續(xù)的改進,，持續(xù)的深入認識某一件事物,。就像上面所說的新業(yè)務(wù)需要不斷的加入，原先業(yè)務(wù)需要不斷的優(yōu)化,。所以需要持續(xù)改進的過程,。這里的持續(xù)改進就需要持續(xù)的業(yè)務(wù)運營數(shù)據(jù)反饋與持續(xù)的添加系統(tǒng)。這個也可以在之后的文章中說明,。

總結(jié)：

在建設(shè)完成微服務(wù)群之后,，需要考慮之后的很多事情。這里說明的持續(xù)改進只不過是其中的一小部分,。我們可以從不同的角度進行考慮以更好的指導(dǎo)之后的技術(shù)工作,。

參考：

VUCA