不管是SOA還是微服務(wù)，它們本質(zhì)上都是服務(wù),，服務(wù)的碎片化看上去帶來了物理上的解耦以及數(shù)據(jù)上更多的自主,，目標(biāo)是更快速地適應(yīng)了業(yè)務(wù)的變化。但I(xiàn)T系統(tǒng)對(duì)于用戶來說永遠(yuǎn)是一個(gè)整體,，離散化帶來了更大的集成難度,，通過元數(shù)據(jù)+流程，描述和編排碎片化的服務(wù),，是實(shí)現(xiàn)服務(wù)集成的捷徑,。

本文主要內(nèi)容是關(guān)于數(shù)據(jù)、流程與服務(wù)之前的關(guān)系,，以及在服務(wù)編排上的一些思考（服務(wù)編排是一種傳說中的快速開發(fā)手段）,。有一些觀點(diǎn)可能比較理想，也缺乏落地的實(shí)踐驗(yàn)證,，在此期望能給大家有所啟發(fā),，如果你想和作者交流,，歡迎掃描文末二維碼加作者微信,。本文的主要內(nèi)容包括：

• 數(shù)據(jù)、流程與服務(wù)之間的關(guān)系

• 服務(wù)適配與數(shù)據(jù)有著千絲萬縷的關(guān)系

• 業(yè)務(wù)邏輯和業(yè)務(wù)流程應(yīng)該可以相互轉(zhuǎn)換

• 服務(wù)離散化之后的工程化協(xié)作與平臺(tái)支撐

這是維基百科描述SOA的一張圖,，很多時(shí)候是我們狹隘了,，認(rèn)為SOA就是基于SOAP的Web Service。

SOA里關(guān)于Service的子概念,，還有Contract,、Interface、Implementation以及Implementation的子概念Business logic、Data,。

很多互聯(lián)網(wǎng)公司,，都極力排斥ESB，不僅僅是在商業(yè)上排斥,，還在技術(shù)上排斥（容易成為性能瓶頸）,，還有一些在企業(yè)投資組合上的決策這里就不展開了?？墒?，最近API Gateway又開始被廣泛提及（包括互聯(lián)網(wǎng)公司）。
以前,，我們用WAR交付的時(shí)候,，里面包含了太多的內(nèi)容。前端,、后端,、業(yè)務(wù)邏輯、數(shù)據(jù)訪問都在一個(gè)WAR里,。于是我們把上面這種形式的WAR,，在架構(gòu)上歸了一個(gè)類，叫Monolithic ,。

Services包含了大量的業(yè)務(wù)邏輯,，即便是在ESB中進(jìn)行所謂的「服務(wù)編排」，程序員還是要寫很多控制代碼,、數(shù)據(jù)適配代碼,。
現(xiàn)在又開始流行「微服務(wù)」，好像只要把Interface,、implementation,、Bussness Logic，編譯打包在一起,，就可以成為一個(gè)Service了,。當(dāng)然還有各種好處，靈活部署,，支持水平擴(kuò)展,，交付迅速。

暫時(shí)不想在「微服務(wù)」這個(gè)概念上做過多的糾纏,，至少有一點(diǎn)是公認(rèn)的事實(shí),，它是可獨(dú)立運(yùn)行的。

這張圖里面有幾個(gè)核心概念,，構(gòu)成了服務(wù)：API,、SPI,、DAI。我在這里需要簡(jiǎn)單的做一下后續(xù)內(nèi)容的術(shù)語約定,。

• API是一個(gè)古老的概念,，來自于PC桌面應(yīng)用時(shí)代，它主要描述的是一段程序,，對(duì)外提供的可被其他程序使用的功能,。對(duì)于服務(wù)而言，API描述對(duì)外提供的功能,。

• SPI并不是我發(fā)明的,，只是大家提的比較少，其實(shí)在JDK中,，有不少SPI的設(shè)計(jì)模式,，主要是用來描述希望外部程序有哪些功能可以被直接使用。有興趣的,，可以去翻一翻JDK,。我對(duì)SPI的定位是，屏蔽其它相關(guān)系統(tǒng)的數(shù)據(jù)模型轉(zhuǎn)換和網(wǎng)絡(luò)通信,，讓業(yè)務(wù)邏輯的上下文環(huán)境更純凈,。

• DAI也許是我創(chuàng)造的，或許別人也提過,，我孤陋寡聞了,。主要目的是讓業(yè)務(wù)邏輯執(zhí)行過程中，對(duì)于數(shù)據(jù)的操作變得簡(jiǎn)單,，不用特別關(guān)心是緩存還是數(shù)據(jù)庫,，是分庫分表還是多活，總之是面向業(yè)務(wù)邏輯友好,。

• SPI和DAI都是站在服務(wù)的視角,，看待所使用的資源，包括其它橫向服務(wù)提供的功能資源（SPI）和縱向的數(shù)據(jù)資源（DAI）,。

再說說,，業(yè)務(wù)邏輯和業(yè)務(wù)流程。一般來說,，業(yè)務(wù)邏輯沒有人的參與,，而業(yè)務(wù)流程有人的參與。

即便是在互聯(lián)網(wǎng)公司,，員工內(nèi)部報(bào)銷,、采購之類的,，還得在內(nèi)部IT系統(tǒng)走報(bào)銷流程吧,，不太能夠做到像在電商下單買東西一樣自助,、自動(dòng)（那些都是業(yè)務(wù)邏輯）。

另外,，再補(bǔ)充說明一下,，關(guān)于MiddlePipe和MiddleBox兩種設(shè)計(jì)模式。

圖中的所有紅框,，都代表一個(gè)運(yùn)行期的進(jìn)程（后續(xù)圖中,，也用類似方法表示，不再額外特別說明）,。MiddleBox和MiddlePipe是兩種在功能上是等價(jià)的,，不同的部署模型。

一個(gè)建議是,，在企業(yè)內(nèi)部系統(tǒng),，盡可能的采用MiddlePipe部署模式，避免MiddleBox模式出現(xiàn),。因?yàn)樵谙到y(tǒng)擴(kuò)容的時(shí)候,，每部署一套系統(tǒng)，MiddleBox模式都需要部署4個(gè)獨(dú)立進(jìn)程,，或者不部署MiddleBox中的Function1 Function2,，這樣會(huì)很容易形成性能瓶頸。ESB就是這種模式,。

根據(jù)前面約定的術(shù)語,，簡(jiǎn)單看一下從前端/終端，到業(yè)務(wù)邏輯（流程）以及數(shù)據(jù)持久化的一個(gè)數(shù)據(jù)流轉(zhuǎn)關(guān)系,。

1. 一個(gè)App如果后端只依賴一個(gè)服務(wù),，且這個(gè)服務(wù)不依賴其它的服務(wù)，這種模式叫做前后端分離,。

2. 一個(gè)App如果后端只依賴一個(gè)服務(wù),，且這個(gè)服務(wù)又依賴多個(gè)的服務(wù)，這種模式叫做微服務(wù)架構(gòu),。

3. 如果一個(gè)App和Service耦合在一起,，這種模式是SOA ，monolithic architecture和service也降級(jí)為同一個(gè)進(jìn)程中的module,。

4. 另外,，API Gateway應(yīng)當(dāng)具備快速部署的能力，處于安全隔離的原因,，API Gateway需要采用獨(dú)享的模式,，和App進(jìn)行一對(duì)一的綁定。

5. 至于Service是否依賴數(shù)據(jù)庫或者數(shù)據(jù)持久化能力,，不一定,。

可以明顯地感覺到,，服務(wù)離散化之后，數(shù)據(jù)也跟著離散化了,，如果不進(jìn)行有效的架構(gòu)管控的話,，每個(gè)服務(wù)都有權(quán)利自己維護(hù)自己的后端數(shù)據(jù)（「會(huì)制造出更多的平行宇宙」這句話不一定好理解）。

MiddleBox模式也不是一無是處,，要看用著什么地方,，比如采用這種模式的API Gateway。

API Gateway一般出現(xiàn)在企業(yè)邊界,，做統(tǒng)一的安全控制,。比如面向app的，面向web的,，面向企業(yè)合作伙伴的（OpenAPI）,。

服務(wù)的本職工作，是處理數(shù)據(jù),。當(dāng)然,，服務(wù)不僅需要根據(jù)業(yè)務(wù)邏輯處理數(shù)據(jù)，還需要協(xié)同其他服務(wù)處理數(shù)據(jù),。

自左向右是三種處理方式,，從簡(jiǎn)單到復(fù)雜。最右面這種也是最常見的（當(dāng)然也是簡(jiǎn)化過的）,。

publisher和subscriber,，是站在數(shù)據(jù)的角度進(jìn)行的命名，前者是客戶端,，后者是服務(wù)端,。之所以這樣命名，一個(gè)原因是,，服務(wù)之間的調(diào)用關(guān)系,，首選異步模式。

• 每個(gè)紅框是一個(gè)進(jìn)程,，代表一個(gè)原子的功能或者能力,。

• 每個(gè)服務(wù)，由Controller負(fù)責(zé)調(diào)用后續(xù)其他的subscriber,。

可以看出來,，MiddleBox模式，Controller非常類似ESB,；反過來MiddlePipe又非常像Dubbo,。在多級(jí)級(jí)聯(lián)之后，展開的應(yīng)該是張圖,，并且是有向圖,。

為什么很多優(yōu)化算法無法在交易型的業(yè)務(wù)系統(tǒng)中得到優(yōu)化,，因?yàn)槊總€(gè)服務(wù)對(duì)于算法來說，都是一個(gè)黑盒,，無法建模,，更無法優(yōu)化,。服務(wù)離散化之后,，黑盒被打開了。

既然抽象出了Controller這個(gè)概念,，作為服務(wù)運(yùn)行期的「集成者」,，需要深入的研究一下如何快速做集成，看下偽代碼,。

假設(shè)有 f_A, f_B, f_C, f_R四個(gè)function是其他服務(wù)提供的API,，其中f_R是服務(wù)本身的內(nèi)部function，其入?yún)⑹?f_A, f_B, f_C 的返回結(jié)果,。

從BEFORE到AFTER是兩種不同的controller實(shí)現(xiàn)形式,。對(duì)于，BEFORE,，描述的更像是程序員硬編碼的業(yè)務(wù)邏輯（人肉模式）,。對(duì)于，AFTER,，main function 是程序員編寫的,，里面調(diào)用了一個(gè)controller的框架，實(shí)現(xiàn)了「多個(gè)服務(wù)的集成」,。mr_controller程序員不需要關(guān)系實(shí)現(xiàn),，只需要關(guān)心如何使用。mr_controller在處理邏輯上,，類似：

• 進(jìn)程內(nèi)的 fork/join

• 進(jìn)程間的 map/reduce

不同之處在與,，還需要mr_controller自動(dòng)完成對(duì)于針對(duì)f_A, f_B, f_C異常處理的「標(biāo)準(zhǔn)動(dòng)作」：

• 框架自動(dòng)補(bǔ)償

• 框架自動(dòng)重試

BEFORE和AFTER是兩個(gè)極簡(jiǎn)單的例子，方法體的本質(zhì)是上下文的Context,，由于簡(jiǎn)化,，沒有出現(xiàn)數(shù)據(jù)的模型轉(zhuǎn)換和臨時(shí)變量，但是,，一般情況下f_R入?yún)⑹茿 B C的變形結(jié)構(gòu),。

接下來再談?wù)凜ontroller的上下文維護(hù)。

• 上游的服務(wù)Context,，依賴下游接口返回值的部分?jǐn)?shù)據(jù)是常態(tài),，比如，只使用下游接口返回值中的某個(gè)ID,。

• 數(shù)據(jù)適配工作大部分都是靠程序員編碼完成,，程序員大腦是「元數(shù)據(jù)倉庫（也就是類庫）」的索引,。

• 一般元數(shù)據(jù)不參與接口調(diào)用，開發(fā)期引用類定義,，其實(shí)是引用元數(shù)據(jù),。

• 一般泛型接口，元數(shù)據(jù)會(huì)在使用時(shí)參與調(diào)用,。如果,，傳入class，其實(shí)是傳入元數(shù)據(jù),。如果,，傳入class的名字，其實(shí)是傳入元數(shù)據(jù)的ID,，由class loader找到class,。

在數(shù)據(jù)領(lǐng)域的MOF中這樣定義元數(shù)據(jù)及其概念和關(guān)系的：

• 元數(shù)據(jù)定義數(shù)據(jù)

• 元模型定義元數(shù)據(jù)

• 元元模型定義元模型

由上往下就是：

• 數(shù)據(jù)實(shí)現(xiàn)元數(shù)據(jù)

• 元數(shù)據(jù)實(shí)現(xiàn)元模型

• 元模型實(shí)現(xiàn)元元模型

程序員在應(yīng)用層的代碼里，主要是在做哪些事呢,？我來總結(jié)下：

1,、編寫代碼的前提條件

• 了解業(yè)務(wù)背景 了解業(yè)務(wù)知識(shí)

2、設(shè)計(jì)并實(shí)現(xiàn)Controller,、Context,、DTO

• Controller: 琢磨需要和組合到那幾個(gè)其他領(lǐng)域功能（API / SPI）

• Context: 設(shè)計(jì)一些用戶保持上下文的變量（在Scala里，是val不是var）

• DTO: 對(duì)過程中返回值進(jìn)行模型變換

3,、附加的處理一些計(jì)算機(jī)的技術(shù)問題

• RPC：異步,？回調(diào) : 同步，超時(shí),？客戶端 : 服務(wù)端

• 運(yùn)行環(huán)境基線不標(biāo)準(zhǔn)

• PaaS層支撐有限

這部分的軟件功能,，基本上是用人肉在做業(yè)務(wù)規(guī)則的翻譯。并且每次做業(yè)務(wù)變更的時(shí)候,，就類似老鷹抓小雞,，業(yè)務(wù)是老鷹，牽一發(fā)而動(dòng)全身,。這樣的程序員好累,，又要懂業(yè)務(wù)邏輯，也要懂技術(shù)實(shí)現(xiàn),。

想要直接編排服務(wù),，并且即時(shí)生效？

對(duì)于服務(wù)編排本身,，是一個(gè)業(yè)務(wù)規(guī)則的映射,、翻譯工作。服務(wù)運(yùn)行期加工的數(shù)據(jù)是什么？是業(yè)務(wù)概念在不同場(chǎng)景下的結(jié)構(gòu)化對(duì)象,。

數(shù)據(jù)適配的工作量占比集成工作很高,。數(shù)據(jù)適配的范圍是入?yún)⑴c出參，上下文臨時(shí)變量,。

• 面向出參的適配：GraphQL,。

• 面向入?yún)⒌倪m配：萬能入?yún)⒌牡慕涌谠O(shè)計(jì)不是好事，過多的分支判斷,，會(huì)將多個(gè)業(yè)務(wù)邏輯耦合在一起,。

• 上下文臨時(shí)變量：目前而言，完全由程序員手工完成,。
  

業(yè)務(wù)架構(gòu),，主要和兩個(gè)方面有關(guān)：數(shù)據(jù)和流程,。在數(shù)據(jù)領(lǐng)域,，數(shù)據(jù)管理里面又有元數(shù)據(jù)和數(shù)據(jù)標(biāo)準(zhǔn)兩個(gè)相輔相成的專業(yè)領(lǐng)域。原本元數(shù)據(jù)和數(shù)據(jù)標(biāo)準(zhǔn)服務(wù)的對(duì)象是數(shù)據(jù)類應(yīng)用,，數(shù)據(jù)源也是來自于「交易型」業(yè)務(wù)系統(tǒng)的數(shù)據(jù)沉淀,，并且經(jīng)過ETL等工作，提煉為「主數(shù)據(jù)」,。

元數(shù)據(jù),，很少在「交易型」業(yè)務(wù)系統(tǒng)中內(nèi)應(yīng)用（主要做數(shù)據(jù)的人不做交易型應(yīng)用，做交易型系統(tǒng)的人不做數(shù)據(jù)類應(yīng)用,，有點(diǎn)進(jìn)水不犯河水的感覺）,。在這里，我的一個(gè)觀點(diǎn)是「拓展元數(shù)據(jù)的應(yīng)用場(chǎng)景」,，對(duì)API,、SPI等接口的入?yún)⑦M(jìn)行管理。有條件的,，直接通過元數(shù)據(jù)管理系統(tǒng),，生成這些參數(shù)的class代碼。

另外,，服務(wù)目錄和業(yè)務(wù)流程之間的關(guān)系,，應(yīng)該是「點(diǎn)和線的關(guān)系」，服務(wù)是點(diǎn),，流程是線,。實(shí)現(xiàn)服務(wù)可編排的三個(gè)要素包括：Controller、Context,、DTO,。下面我逐一做下解釋：

• Controller，基本上是業(yè)務(wù)邏輯的映射。

• Controller能夠正常工作需要Context這個(gè)「秘書」的協(xié)助,。Context中的臨時(shí)變量,，應(yīng)該可以通上游API入?yún)⒌臄?shù)據(jù)類型和下游SPI入?yún)⒌臄?shù)據(jù)類型，結(jié)合元數(shù)據(jù)進(jìn)行推斷,。

• DTO完成多到一的數(shù)據(jù)轉(zhuǎn)換是基本功能,，這也是要和元數(shù)據(jù)緊密結(jié)合的。

Controller的實(shí)現(xiàn)有三種方式,，具體如下：

方式一：作為通用引擎 運(yùn)行期 元數(shù)據(jù)解析（性能慢）

• 動(dòng)態(tài)加載流程元數(shù)據(jù)

• 根據(jù)上游元數(shù)據(jù)動(dòng)態(tài)解析上游數(shù)據(jù)

• 根據(jù)下游元數(shù)據(jù),，動(dòng)態(tài)構(gòu)造下游入?yún)?shù)據(jù)以及報(bào)文，再調(diào)用下游接口

方式二：開發(fā)期 直接生成代碼（性能高,，但需要工具支撐）

• 聲明內(nèi)部變量

• 接口調(diào)用與返回值變量賦值

• 上下文數(shù)據(jù)類型轉(zhuǎn)換

方式三：運(yùn)行期 根據(jù)生成代碼（性能高,，第一次慢）

• 具體方式類似于JSP的原理

• 第一次運(yùn)行比較慢

簡(jiǎn)單補(bǔ)充下，方式一中Controller可以是個(gè)Library,，直接在編譯期打包集成,。可以適用于MiddlePipe和MiddleBox兩種部署模式,。Controller依賴的Context里面的臨時(shí)變量,，在運(yùn)行期基本上以Map、Aarray這種弱類型,，通過外部封裝的邏輯對(duì)其維護(hù),。

方式二和方式三：生成的代碼，和程序員寫的代碼類似,，都會(huì)在Controller方法體內(nèi),，聲明變量，這些臨時(shí)變量的交由JVM之類的進(jìn)行托管,。

對(duì)于業(yè)務(wù)流程（也就是一般情況下,，有人參與的情況），Context不能被長(zhǎng)期的置于內(nèi)存中,，需要外置,。再進(jìn)一步的，Controller和Context Service部署在一起,，就變成了流程服務(wù),，MiddleBox的部署模式。

這種模式,，和ESB很像,。說了很多關(guān)于流程以及數(shù)據(jù)的結(jié)合點(diǎn)，回過頭來再說說服務(wù)本身,，有哪些非功能要求,。

說了很多關(guān)于流程以及數(shù)據(jù)的結(jié)合點(diǎn)，回過頭來再說說服務(wù)本身，有哪些非功能要求,。 

服務(wù)端

• 面向資源的接口風(fēng)格（REST是一種參考實(shí)現(xiàn)）  http(s):////

• 保證接口冪等性（注意,，使用HTTP PUT創(chuàng)建，而不是POST）,。（冪等） PUT 是客戶端生成 資源ID（PUT http(s):////）,，（非冪等）POST 是服務(wù)端生成 資源ID（POST http(s):///）。

• 提供進(jìn)度查詢方法 （例如,，采用HTTP HEAD）,。

• 提供補(bǔ)償（沖正/反交易）接口（例如，采用HTTP DELETE）,。

• 提供默認(rèn)超時(shí)時(shí)間,，并以客戶端超時(shí)時(shí)間為優(yōu)先。

客戶端

• 能夠直接得到服務(wù)端是否處理的回復(fù)

• 能夠查詢處理的進(jìn)度,，以及超時(shí)時(shí)間

• 處理完的結(jié)果：整體的成功還是失敗,、同步結(jié)果告知或者提供接口被回調(diào)。

上下文

• 臨時(shí)變量的自動(dòng)化生成

• 數(shù)據(jù)類型的自動(dòng)轉(zhuǎn)換

客戶端不關(guān)心

• 在服務(wù)端的背后,，有多少個(gè)服務(wù)根據(jù)什么流程進(jìn)行協(xié)同處理

解放生產(chǎn)力,，就是不斷把新產(chǎn)生的「人維護(hù)的上下文」的重復(fù)性工作交給系統(tǒng),。處理未知風(fēng)險(xiǎn),，不斷把計(jì)算機(jī)執(zhí)行的業(yè)務(wù)邏輯所產(chǎn)生的位置業(yè)務(wù)風(fēng)險(xiǎn)，轉(zhuǎn)交給人,。

服務(wù)的拆解，不一定全都是帶來紅利,，也得交點(diǎn)稅,。保障當(dāng)前離散化服務(wù)持續(xù)交付，一些在工程落地實(shí)踐上的建議：

• 一個(gè)原子業(yè)務(wù)能力的定義包括：API / SPI / DAI 定義以及單元測(cè)試用例以及Mock數(shù)據(jù),，并由代碼生成文檔,。

• 代碼的定義與實(shí)現(xiàn)充分解耦，架構(gòu)師負(fù)責(zé)定義,，開發(fā)工程師負(fù)責(zé)實(shí)現(xiàn),，并將定義盡可能的上升為標(biāo)準(zhǔn)。

• API / SPI 中的參數(shù)對(duì)象遵循數(shù)據(jù)標(biāo)準(zhǔn),，有在線的元數(shù)據(jù)系統(tǒng)對(duì)其進(jìn)行統(tǒng)一管理,。

• SPI 的實(shí)現(xiàn)，不允許做數(shù)據(jù)持久化操作,。

• 支撐IT的IT平臺(tái)：這個(gè)平臺(tái)目前基本上是DevOps,，以及「泛DevOps」。

• 對(duì)運(yùn)行環(huán)境的要求。這個(gè)環(huán)境目前基本上是Docker,，對(duì)于老系統(tǒng)的改造路徑,，主要是改造類型應(yīng)用服務(wù)器的中間件，并做好基線管理,。

前文講了很多如何實(shí)現(xiàn)業(yè)務(wù)邏輯的內(nèi)容,，但是沒有講如何自動(dòng)生成測(cè)試用例，因?yàn)檫@些方面還沒有進(jìn)行思考,。人的精力是有限的,，當(dāng)架構(gòu)師、開發(fā)工程師的工作部分被計(jì)算機(jī)所承擔(dān)的時(shí)候,，可以更多的去關(guān)注非正常的業(yè)務(wù)規(guī)則,。

上面是個(gè)跨行業(yè)的例子,，并且只是示意,。對(duì)于企業(yè)內(nèi)部而言，不同行業(yè)就如同不同的業(yè)務(wù)部門,。服務(wù)的離散化,，導(dǎo)致數(shù)據(jù)的離散化、軟件交付過程中相應(yīng)職能與職責(zé)的離散化,，更多的參與者能夠接觸到數(shù)據(jù),，業(yè)務(wù)的組合出現(xiàn)更多的不確定性。在業(yè)務(wù)流程的制定上,，無法完全描述全量的業(yè)務(wù)模型,，導(dǎo)致出現(xiàn)各方全都正確，但最終出現(xiàn)非法業(yè)務(wù)的情況,。業(yè)務(wù)安全性分析,，需要借助AI、ML等工具與平臺(tái)進(jìn)行風(fēng)險(xiǎn)控制,。

IT 系統(tǒng)是處理數(shù)據(jù)的,，事件、流,、存量,，是數(shù)據(jù)源的三種不同形態(tài)，對(duì)應(yīng)了三種不同的處理模式,。本次內(nèi)容談了多對(duì)于服務(wù)的思考,，但是遠(yuǎn)遠(yuǎn)不夠的，最多是1/3,。

啰嗦了很多,，最后總結(jié)一些思考過程中的一些感想,。

• 軟件大體上解決兩類問題人的問題，也就是業(yè)務(wù)的問題計(jì)算機(jī)的問題,，也就是技術(shù)的問題,。

• 軟件越貼近業(yè)務(wù)功能實(shí)現(xiàn)，在不同場(chǎng)景下對(duì)數(shù)據(jù)的適配越多,，但支撐的工具和平臺(tái)太少,。

• 人，是一種適配功能很強(qiáng)的「適配器」,。

• 人,，對(duì)于模糊、定性的描述理解更為準(zhǔn)確定性的描述,，外延更大,，受體可以自己自由適配舉例：進(jìn)出地鐵，站在扶梯上,，會(huì)有語音提示「上下樓梯,，請(qǐng)緊握扶手」可，「緊」,，對(duì)于計(jì)算機(jī)程序是什么,？用手施加10牛頓的力嗎？

• 做好產(chǎn)品的簡(jiǎn)單原則：基于本質(zhì),，懂得人性,。

王延炯，密碼學(xué)博士,，現(xiàn)任普元信息軟件產(chǎn)品部主任架構(gòu)師,。畢業(yè)于北京郵電大學(xué)網(wǎng)絡(luò)與交換技術(shù)國家重點(diǎn)實(shí)驗(yàn)室網(wǎng)絡(luò)安全中心。曾先后任職于西門子（中國）研究院,、普元信息、垂直行業(yè)互聯(lián)網(wǎng)公司,。帶領(lǐng)團(tuán)隊(duì)交付了移動(dòng),、金融、電信,、廣電,、移動(dòng)互聯(lián)網(wǎng)等多個(gè)行業(yè)、眾多IT系統(tǒng)的咨詢,、設(shè)計(jì),、研發(fā)、實(shí)施,、維護(hù),、優(yōu)化工作,。對(duì)分布式架構(gòu)，企業(yè)架構(gòu),，以及企業(yè)IT平臺(tái)化運(yùn)營(yíng)有深入的研究和理解,。

歡迎掃描二維碼加入由作者主持的“普元云計(jì)算研發(fā)開放群”，討論更多微服務(wù),、DevOps,、容器相關(guān)內(nèi)容，加群暗號(hào)“微服務(wù)”,。