分享篇
如何降低企業(yè)互聯(lián)網(wǎng)化改造的技術(shù)門檻？如何提高企業(yè)的業(yè)務(wù)快速響應(yīng)能力及業(yè)務(wù)創(chuàng)新能力？在本期大華南IT高管共贏圈的微課分享中，互聯(lián)網(wǎng)架構(gòu)資深專家柳杰先生結(jié)合多年知名互聯(lián)網(wǎng)公司的從業(yè)經(jīng)歷，以及對(duì)企業(yè)中臺(tái)化改造的豐富實(shí)踐經(jīng)驗(yàn)，與大華南平臺(tái)CIO分享了實(shí)現(xiàn)企業(yè)架構(gòu)中臺(tái)化的秘訣。
企業(yè)應(yīng)用的變遷過程
企業(yè)應(yīng)用的變遷過程主要分為幾個(gè)階段，2000年，主要是單一應(yīng)用，是企業(yè)為了增加效益而開發(fā)的應(yīng)用。2000到2004年這個(gè)階段，雖然，企業(yè)做了很多的C/S的應(yīng)用，運(yùn)維相當(dāng)?shù)膹?fù)雜。企業(yè)也在尋找新的技術(shù)方向，當(dāng)WEB容器、B/S結(jié)構(gòu)出現(xiàn)之后，企業(yè)應(yīng)用如雨后春筍般的，快速出現(xiàn)很多B/S結(jié)構(gòu)的系統(tǒng)，大部分都是以部門或項(xiàng)目為單位開發(fā)一些垂直應(yīng)用，這些垂直應(yīng)用對(duì)企業(yè)的生產(chǎn)發(fā)揮了重要作用，提升了效率，加強(qiáng)了管理。2006年到2008年這個(gè)階段，隨著業(yè)務(wù)的發(fā)展，企業(yè)需要進(jìn)行業(yè)務(wù)融合，將數(shù)據(jù)打通，這時(shí)候就出現(xiàn)SOA服務(wù)，主要解決企業(yè)應(yīng)用、業(yè)務(wù)協(xié)調(diào)和數(shù)據(jù)共享的問題。這一階段，很多企業(yè)實(shí)施了ESB，面向服務(wù)重用、流程重構(gòu)，以達(dá)到業(yè)務(wù)的靈活性。但在實(shí)施過程中，由于只站在業(yè)務(wù)的部門、項(xiàng)目的角度去思考問題，沒有將業(yè)務(wù)分析的高度提高到整個(gè)公司或者集團(tuán)的角度。比如兩個(gè)業(yè)務(wù)系統(tǒng)之間做一些服務(wù)的交互或業(yè)務(wù)的交互，這實(shí)際上就變成了數(shù)據(jù)的一個(gè)交換通道，大多數(shù)最后都做成的是數(shù)據(jù)交換平臺(tái)，沒有到達(dá)業(yè)務(wù)的共享和協(xié)同。因此實(shí)施SOA存在很多問題，收效甚微?；ヂ?lián)網(wǎng)發(fā)展到2013年至2014年這個(gè)階段，云化服務(wù)開始出現(xiàn)。隨著微服務(wù)架構(gòu)的出現(xiàn)，導(dǎo)致很多企業(yè)的應(yīng)用也發(fā)生了變化，在工業(yè)互聯(lián)網(wǎng)或產(chǎn)業(yè)互聯(lián)網(wǎng)領(lǐng)域，以及企業(yè)應(yīng)用面向消費(fèi)者等方面發(fā)揮了作用。這個(gè)時(shí)候，企業(yè)中并沒有出現(xiàn)真正的微服務(wù)中臺(tái)化的架構(gòu)，但在互聯(lián)網(wǎng)行業(yè)已經(jīng)存在，一些巨型的互聯(lián)網(wǎng)公司實(shí)現(xiàn)了企業(yè)應(yīng)用的云化。
整個(gè)發(fā)展過程中的各階段，基本都是以企業(yè)的業(yè)務(wù)發(fā)展和IT技術(shù)匹配發(fā)展。業(yè)務(wù)推動(dòng)技術(shù)，新技術(shù)助力業(yè)務(wù)發(fā)展。
2015年，一些互聯(lián)網(wǎng)公司提出中臺(tái)化的概念，實(shí)際上在2012年到2013年間，很多互聯(lián)網(wǎng)公司已經(jīng)在實(shí)施，當(dāng)時(shí)叫單元化。這個(gè)單元能夠提供相應(yīng)的領(lǐng)域服務(wù)能力，即IT系統(tǒng)與資源能夠疊加，對(duì)外提供業(yè)務(wù)服務(wù)能力，能根據(jù)資源的量進(jìn)行橫向擴(kuò)展。這個(gè)階段，很多互聯(lián)網(wǎng)企業(yè)在開展促銷活動(dòng)的過程中，經(jīng)常會(huì)出現(xiàn)一種現(xiàn)象，就是同一個(gè)功能，如購物車，有的企業(yè)所設(shè)計(jì)的購物車卻可以支持上億人同時(shí)在線，支撐很大的訪問量，有的企業(yè)開發(fā)相同功能的購物車，可能幾百人上去就搞癱了。這實(shí)際上就是技術(shù)的支撐實(shí)現(xiàn)了業(yè)務(wù)服務(wù)能力的提升。在2015年、2016年之后，出現(xiàn)了新零售、工業(yè)4.0、產(chǎn)業(yè)互聯(lián)網(wǎng)、工業(yè)制造等新概念，這些概念也在沖擊著傳統(tǒng)制造型企業(yè)，企業(yè)開始思考企業(yè)內(nèi)部的協(xié)同生產(chǎn)，產(chǎn)業(yè)互聯(lián)網(wǎng)、消費(fèi)互聯(lián)網(wǎng)資源的打通，柔性制造，用戶個(gè)性化定制等問題，企業(yè)的信息化不再是面向內(nèi)部的信息化，而是要面向用戶、面向渠道，將系統(tǒng)和能力對(duì)外開放，實(shí)現(xiàn)整個(gè)生態(tài)共享。這個(gè)時(shí)候，傳統(tǒng)的ERP或者傳統(tǒng)業(yè)務(wù)應(yīng)用業(yè)務(wù)能力是不夠的，需要有一種新的技術(shù)模式，新的設(shè)計(jì)手段去改變企業(yè)應(yīng)用的服務(wù)能力。
微服務(wù)化的架構(gòu)設(shè)計(jì)
如上圖：微服務(wù)架構(gòu)實(shí)際是紅色虛線內(nèi)的內(nèi)容。
微服務(wù)的架構(gòu)看上去比傳統(tǒng)的架構(gòu)復(fù)雜，提高對(duì)業(yè)務(wù)的快速響應(yīng)能力和服務(wù)能力擴(kuò)展，可以解決企業(yè)的很多問題。微服務(wù)是數(shù)據(jù)獨(dú)立、服務(wù)獨(dú)立和部署獨(dú)立的，能夠作為一個(gè)業(yè)務(wù)組件部署到系統(tǒng)中，獨(dú)立去演進(jìn)，這是微服務(wù)的一大特點(diǎn)。微服務(wù)提供的服務(wù)是領(lǐng)域內(nèi)的服務(wù)。企業(yè)的服務(wù)，如SOA化的時(shí)候，是從公司或者集團(tuán)層面的服務(wù)，而微服務(wù)是從業(yè)務(wù)領(lǐng)域本身的角度出發(fā)，二者是不同層面的事情。微服務(wù)要解決的是服務(wù)能力和業(yè)務(wù)靈活性的問題，業(yè)務(wù)的快速變更對(duì)整個(gè)業(yè)務(wù)應(yīng)用的容錯(cuò)性問題。從整個(gè)設(shè)計(jì)或部署的架構(gòu)上來看，傳統(tǒng)應(yīng)用就是簡單的WAR包和數(shù)據(jù)庫，微服務(wù)體系就要部署N個(gè)微服務(wù)領(lǐng)域?qū)嵗?，業(yè)務(wù)服務(wù)實(shí)例，能力開放平臺(tái)，應(yīng)用場(chǎng)景的war包，然后組裝起來成為一個(gè)應(yīng)用。在傳統(tǒng)的應(yīng)用中，WAR包只能部署在一臺(tái)或者幾臺(tái)機(jī)器上跟數(shù)據(jù)庫綁死，即使有資源也無法進(jìn)行能力擴(kuò)展，而微服務(wù)可以實(shí)現(xiàn)橫向擴(kuò)展，在每個(gè)層級(jí)、各個(gè)環(huán)節(jié)都可以進(jìn)行擴(kuò)展。將IT資源和微服務(wù)、業(yè)務(wù)服務(wù)和業(yè)務(wù)應(yīng)用進(jìn)行疊加，實(shí)現(xiàn)服務(wù)能力橫向擴(kuò)展。
看上去微服務(wù)要比？？
什么是企業(yè)中臺(tái)
微服務(wù)與企業(yè)中臺(tái)是兩個(gè)概念。從微服務(wù)的概念來講，比如，B2B或B2C的電商系統(tǒng)都有會(huì)員中心、商品中心、價(jià)格中心、訂單中心等微服務(wù)，但這兩個(gè)系統(tǒng)的數(shù)據(jù)是隔離的。從企業(yè)中臺(tái)的概念來講，如會(huì)員中心，不管是B2B還是B2C，都只是一個(gè)應(yīng)用交易場(chǎng)景的問題，企業(yè)中臺(tái)可以同時(shí)支撐B2B、B2C兩種場(chǎng)景。
企業(yè)中臺(tái)實(shí)際上是一組微服務(wù)，在微服務(wù)上疊加一些業(yè)務(wù)服務(wù)，如業(yè)務(wù)流程和微服務(wù)的組合服務(wù)等等。企業(yè)中臺(tái)是基于企業(yè)業(yè)務(wù)層面是SOA化的服務(wù)。微服務(wù)是一個(gè)領(lǐng)域模型中的服務(wù)，企業(yè)中臺(tái)是更寬泛的業(yè)務(wù)場(chǎng)景的服務(wù)，如購物車的服務(wù)涉及商品、商戶、門店等各個(gè)微服務(wù)中心。中臺(tái)的業(yè)務(wù)服務(wù)是一種組合服務(wù)，可以進(jìn)行服務(wù)的重組或編排，對(duì)外提供整體的業(yè)務(wù)服務(wù)和服務(wù)能力。因此，企業(yè)中臺(tái)下面有一組微服務(wù)，解決的是服務(wù)能力的問題，IT系統(tǒng)與IT資源可以進(jìn)行疊加，通過底層服務(wù)能力的提供，業(yè)務(wù)能力也會(huì)隨之增強(qiáng)。企業(yè)中臺(tái)可以保證業(yè)務(wù)本身的靈活性，服務(wù)能力可以隨著資源的橫向擴(kuò)展而擴(kuò)展，解決業(yè)務(wù)響應(yīng)慢、性能瓶頸等問題。
如上圖所示， 其中微服務(wù)：
企業(yè)中臺(tái)：
中臺(tái)服務(wù)構(gòu)建方法論
中臺(tái)服務(wù)構(gòu)建方法論，首先，業(yè)務(wù)與技術(shù)是隔離的。業(yè)務(wù)提供的是業(yè)務(wù)功能和業(yè)務(wù)流程，屬于業(yè)務(wù)功能范疇；技術(shù)提供幫助業(yè)務(wù)解決服務(wù)能力問題，屬于技術(shù)范疇。業(yè)務(wù)的組件化，從業(yè)務(wù)領(lǐng)域來講，組件化實(shí)際上是領(lǐng)域的拆分問題，比如：把電商業(yè)務(wù)拆解為：會(huì)員中心、商品中心、店鋪中心、價(jià)格中心、訂單中心等等還有更多中心。把業(yè)務(wù)拆分成組件。組件服務(wù)化，就是組件對(duì)外呈現(xiàn)的形式是一個(gè)一個(gè)的服務(wù)或者一個(gè)一個(gè)的API，最終業(yè)務(wù)組件化、組件服務(wù)化、服務(wù)能力化，即服務(wù)在微服務(wù)體系下，服務(wù)能力與IT資源進(jìn)行疊加時(shí)是可以得到保障的。把業(yè)務(wù)組件化，組件服務(wù)化，服務(wù)能力化，從領(lǐng)域的角度去拆分業(yè)務(wù)域。
將領(lǐng)域拆分后是否就是實(shí)現(xiàn)微服務(wù)？這主要考慮微服務(wù)在提供服務(wù)能力時(shí)是否與資源進(jìn)行疊加。如果不能，則還是與傳統(tǒng)應(yīng)用一樣，在開發(fā)模式下，實(shí)現(xiàn)了把領(lǐng)域拆分，業(yè)務(wù)服務(wù)開發(fā)出來。
技術(shù)主要解決兩個(gè)問題，一是對(duì)服務(wù)本身的管控和治理，如服務(wù)框架；二是解決服務(wù)能力和資源疊加的問題。如果將這些技術(shù)和業(yè)務(wù)捆綁在一起都放在微服務(wù)中心，這實(shí)際上是將技術(shù)與業(yè)務(wù)捆綁在一起，這會(huì)導(dǎo)致業(yè)務(wù)擴(kuò)展性很難落地。比如傳統(tǒng)開發(fā)，一個(gè)業(yè)務(wù)應(yīng)用對(duì)應(yīng)多個(gè)數(shù)據(jù)庫，開發(fā)的時(shí)候在應(yīng)用中配置多個(gè)數(shù)據(jù)源，應(yīng)用根據(jù)某個(gè)或者幾個(gè)關(guān)鍵字端判斷選擇哪個(gè)數(shù)據(jù)源。如果增加一個(gè)數(shù)據(jù)源，系統(tǒng)要做比較大的改動(dòng)，最后不一定成功。
業(yè)務(wù)與技術(shù)分離，業(yè)務(wù)解決的是業(yè)務(wù)的功能和流程問題；技術(shù)解決的是對(duì)功能、流程的能力支撐問題。如果將二者捆綁在一起，很多問題都不能有效解決，尤其在開發(fā)時(shí)，很難從設(shè)計(jì)層面去解決。因此在中臺(tái)構(gòu)建的時(shí)候，業(yè)務(wù)組件關(guān)注的業(yè)務(wù)功能和流程，按照技術(shù)體系要求開發(fā)業(yè)務(wù)功能。業(yè)務(wù)功能運(yùn)行在技術(shù)體系上，技術(shù)體系提供服務(wù)能力，即業(yè)務(wù)應(yīng)用的橫向擴(kuò)展能力。
互聯(lián)網(wǎng)應(yīng)用的中臺(tái)和端
很多企業(yè)經(jīng)常提及的前后端分離，比如H5應(yīng)用、APP、Web應(yīng)用、第三方接入，其實(shí)都是通過中臺(tái)將業(yè)務(wù)開放出去。在我講的中臺(tái)有六層服務(wù)，其中：
數(shù)據(jù)落地層、企業(yè)微服務(wù)層、流程/流程重構(gòu)層是企業(yè)業(yè)務(wù)開發(fā)人員需要設(shè)計(jì)和開發(fā)的數(shù)據(jù)模型設(shè)計(jì)，微服務(wù)、業(yè)務(wù)功能和業(yè)務(wù)流程相關(guān)的部分。數(shù)據(jù)庫服務(wù)層、服務(wù)交互層、RESTful interface是技術(shù)支撐部分。如上圖所示，從底層往上，第一層是服務(wù)能力提供，第二層是業(yè)務(wù)能力提供，第三層是基于業(yè)務(wù)API上的應(yīng)用或應(yīng)用場(chǎng)景的開發(fā)。數(shù)據(jù)與服務(wù)分離，就是數(shù)據(jù)用什么數(shù)據(jù)庫、數(shù)據(jù)在哪里落地，由數(shù)據(jù)庫的服務(wù)層即分布式數(shù)據(jù)庫去解決數(shù)據(jù)本身的路由問題。微服務(wù)的實(shí)例擴(kuò)展時(shí)，數(shù)據(jù)庫的實(shí)例也可以進(jìn)行相應(yīng)的擴(kuò)展。通過分布式數(shù)據(jù)庫解決數(shù)據(jù)與服務(wù)的分離。通過微服務(wù)框架使用業(yè)務(wù)流程與微服務(wù)分離，所謂企業(yè)業(yè)務(wù)的變化，更多變化的是業(yè)務(wù)流程重組或重構(gòu)，微服務(wù)體系在領(lǐng)域內(nèi)，其支撐對(duì)象是很少發(fā)生變化的，基本比較穩(wěn)定。當(dāng)業(yè)務(wù)系統(tǒng)需要重構(gòu)或重寫時(shí)，其實(shí)重寫的是流程，數(shù)據(jù)庫、數(shù)據(jù)模型是沒有發(fā)生變化的。
中臺(tái)與端的分離，實(shí)際上就是前后端的分離，這當(dāng)中很多的服務(wù)是可以共享的，通過中臺(tái)給出同樣的服務(wù)，在前端可以構(gòu)建相應(yīng)的應(yīng)用場(chǎng)景。在企業(yè)或者互聯(lián)網(wǎng)的應(yīng)用中，容易變化的是交互層的東西，比如構(gòu)建一個(gè)用戶交互流程，增強(qiáng)用戶體驗(yàn)等等。中臺(tái)層面的變化，比如流程層面，雖然也有變化，但不如交互層變化快。另外，微服務(wù)的領(lǐng)域模型變化也比較少，變化的內(nèi)容僅僅影響該領(lǐng)域，不會(huì)影響所有領(lǐng)域，再者，通過標(biāo)簽化的設(shè)計(jì)，可以使得微服務(wù)端基本穩(wěn)定，不用 變化。
總結(jié)而言，中臺(tái)最終提供的是業(yè)務(wù)服務(wù)，微服務(wù)是支撐上層的業(yè)務(wù)服務(wù)，通過業(yè)務(wù)服務(wù)支撐上層的企業(yè)應(yīng)用。底層的服務(wù)能力是微服務(wù)提供的，通過資源的疊加，增加服務(wù)能力。微服務(wù)能力能夠保證就有業(yè)務(wù)能力的保障，應(yīng)用端的支撐能力是隨著業(yè)務(wù)能力的增長而增長。應(yīng)用能力最終通過微服務(wù)能力體現(xiàn)。
中臺(tái)如何支撐業(yè)務(wù)場(chǎng)景
中臺(tái)如何支撐業(yè)務(wù)場(chǎng)景，如下圖所示，B2B、O2O都是部署在中臺(tái)，如用戶服務(wù)、搜索、價(jià)格、商品等等，二者的支撐場(chǎng)景都差不多，只是展現(xiàn)模式不一樣。如商品展現(xiàn)，O2O以店鋪為單位展示商品，B2B、B2C是通過引擎將商品搜索出來后，再通過商品列表去進(jìn)行展示。這其實(shí)是一個(gè)場(chǎng)景的問題，底層的支撐端都是一樣的。因此，后臺(tái)一體化，前臺(tái)可以差異化，前臺(tái)差異化其實(shí)就是場(chǎng)景問題。比如構(gòu)建一個(gè)場(chǎng)景，底層的業(yè)務(wù)或服務(wù)不需要再考慮，只需要把端設(shè)計(jì)好，通過API把數(shù)據(jù)提供出來，然后在端上把整個(gè)的操作流程實(shí)現(xiàn)就可以了。
中臺(tái)應(yīng)用的好處
中臺(tái)應(yīng)用的好處主要體現(xiàn)在四個(gè)方面，一是降低開發(fā)風(fēng)險(xiǎn)，提高開發(fā)效率。不需要重新整體設(shè)計(jì)就可以完成整個(gè)應(yīng)用端的開發(fā)，應(yīng)用端的開發(fā)是基于中臺(tái)的API進(jìn)行開發(fā)，這樣就可以提高開發(fā)效率，增加系統(tǒng)的穩(wěn)定性，應(yīng)用端只是構(gòu)建操作流程。二是提升系統(tǒng)擴(kuò)展性，增強(qiáng)服務(wù)伸縮性。三是降低維護(hù)風(fēng)險(xiǎn)，減少維護(hù)成本。微服務(wù)本身部署的復(fù)雜度、系統(tǒng)和測(cè)試的復(fù)雜度等等，比傳統(tǒng)的要復(fù)雜，在互聯(lián)網(wǎng)行業(yè)都有一套很好的工具去解決這些問題，人為的出錯(cuò)幾率要小很多。四是簡化運(yùn)維難度，提升管理效率。在互聯(lián)網(wǎng)行業(yè)有一套技術(shù)支撐體系去支撐應(yīng)用的快速部署、運(yùn)維和管理。運(yùn)維在互聯(lián)網(wǎng)行業(yè)也有一套監(jiān)控的運(yùn)維體系，在進(jìn)行容量規(guī)劃或擴(kuò)容、服務(wù)改造等等，都做了相應(yīng)的數(shù)據(jù)化運(yùn)維，降低了整個(gè)運(yùn)維難度和成本，很多都是通過工具化去解決，可以提前告警?；ヂ?lián)網(wǎng)的應(yīng)用可以監(jiān)控到每一個(gè)API的情況。
技術(shù)與業(yè)務(wù)分離，技術(shù)解決運(yùn)維、發(fā)布、服務(wù)治理管控、服務(wù)開放和服務(wù)能力等問題，業(yè)務(wù)只是進(jìn)行開發(fā)。企業(yè)業(yè)務(wù)開發(fā)人員只專注業(yè)務(wù)功能和業(yè)務(wù)流程的開發(fā)。
如何構(gòu)建穩(wěn)定的企業(yè)中臺(tái)架構(gòu)
構(gòu)建穩(wěn)定的企業(yè)中臺(tái)架構(gòu)，實(shí)際上就是要解決統(tǒng)一企業(yè)架構(gòu)、服務(wù)能力、服務(wù)和資源疊加、集中運(yùn)維平臺(tái)等問題，包括從開發(fā)到運(yùn)維的全生命周期的服務(wù)技術(shù)支撐。將企業(yè)從技術(shù)架構(gòu)，應(yīng)用架構(gòu)中解放出來，關(guān)注業(yè)務(wù)本身。在微服務(wù)體系，不需要統(tǒng)一技術(shù)體系是可以的，可以是Java，.net，PHP等技術(shù)，但在架構(gòu)層面，比如服務(wù)的管控框架、治理框架，分布式數(shù)據(jù)等等，在架構(gòu)層面需要有一套系統(tǒng)規(guī)范。微服務(wù)在設(shè)計(jì)的時(shí)候要保證服務(wù)能力就可以了。
如上圖所示：應(yīng)用是各類場(chǎng)景問題，如上圖：B2B，O2O只是交易場(chǎng)景的問題，底層的支持是一樣的，比如：會(huì)員中心，店鋪中心，商品中心，價(jià)格中心，交易中心等等，支撐能力相同或者有些變化，但在應(yīng)用場(chǎng)景上變化很大。
尤其在未來，企業(yè)在發(fā)展的過程中，應(yīng)用場(chǎng)景會(huì)逐步增加。在中臺(tái)的體系支撐之下，構(gòu)建應(yīng)用場(chǎng)景比傳統(tǒng)的方式快很多，同時(shí)應(yīng)用的穩(wěn)定性要高很多。逐漸體現(xiàn)出中臺(tái)的價(jià)值。
如何構(gòu)建穩(wěn)定的中臺(tái)架構(gòu)
中臺(tái)實(shí)際上是一個(gè)業(yè)務(wù)服務(wù)的問題，但是技術(shù)需要給他賦能，在開發(fā)的過程中，需要有一定的規(guī)范和最佳實(shí)踐來支撐，在設(shè)計(jì)方面，我們要解決：
1、 統(tǒng)一的技術(shù)架構(gòu)體系也業(yè)務(wù)架構(gòu)體系（微服務(wù)體系）
2、 服務(wù)能力要保證，如果服務(wù)能力不能保證，和傳統(tǒng)模式開發(fā)一個(gè)應(yīng)用在本質(zhì)上沒有什么區(qū)別
3、 服務(wù)和資源的疊加，是解決服務(wù)能力的根本保證，否則，會(huì)出現(xiàn)服務(wù)的性能瓶頸。
4、 需要一套運(yùn)維體系。服務(wù)的數(shù)量很大，沒有一套自動(dòng)運(yùn)維體系是很難保證的。
整體互聯(lián)網(wǎng)業(yè)務(wù)架構(gòu)
基于PasS平臺(tái)開發(fā)出來的應(yīng)用，其邏輯上的架構(gòu)是怎樣的？如上圖所示：IaaS層：物理機(jī)、私有云、公有云等都是屬于IaaS部分，不做任何挑選，多種IaaS環(huán)境均可無縫支持。在PasS層，目前大型的互聯(lián)網(wǎng)公司基本是使用JAVA體系，JAVA體系本身在JAVA虛擬機(jī)上，服務(wù)和應(yīng)用的遷移，對(duì)操作系統(tǒng)沒有要求。
業(yè)務(wù)服務(wù)體系，就是中臺(tái)，基于A-PasS和I-PaaS中臺(tái)，上層的B2B、O2O、B2C都是屬于應(yīng)用場(chǎng)景。因此，按照這種框架進(jìn)行開發(fā)，關(guān)鍵問題是識(shí)別領(lǐng)域里的服務(wù)，技術(shù)上是可以通過PaaS平臺(tái)做一個(gè)完整的支撐，包服務(wù)框架、統(tǒng)一運(yùn)維的監(jiān)控、自動(dòng)化調(diào)度、資源調(diào)度、資源的告警和實(shí)時(shí)查看等等。
大數(shù)據(jù)平臺(tái)單獨(dú)劃分，在傳統(tǒng)企業(yè)中，數(shù)據(jù)平臺(tái)作為企業(yè)的數(shù)據(jù)資產(chǎn)或數(shù)據(jù)資源，在日常的企業(yè)運(yùn)營中，尤其是系統(tǒng)的交互層面是很少有的，大部分以報(bào)表的方式是為企業(yè)提供決策。在互聯(lián)網(wǎng)公司，日常的運(yùn)營中都是基于大數(shù)據(jù)平臺(tái)來進(jìn)行的，采集各類運(yùn)行性能數(shù)據(jù)，對(duì)數(shù)據(jù)做分析，然后告知運(yùn)維。企業(yè)在使用數(shù)據(jù)時(shí)，大部分都是采用結(jié)果數(shù)據(jù)，過程數(shù)據(jù)、行為數(shù)據(jù)目前在企業(yè)中應(yīng)用較少。因此，對(duì)數(shù)據(jù)的采集、數(shù)據(jù)的收集渠道、數(shù)據(jù)源等可以做到更加多樣化。
每個(gè)環(huán)節(jié)的組件支撐
在JAVA的整個(gè)開發(fā)體系中，主要解決：面向研發(fā)和面向運(yùn)維。比如面向研發(fā)的時(shí)候，整個(gè)開發(fā)體系在支撐時(shí)要解決開發(fā)環(huán)境、技術(shù)框架、應(yīng)用架構(gòu)等問題。研發(fā)完成后，進(jìn)行集成和自動(dòng)部署，在自動(dòng)部署上生產(chǎn)之后，面向運(yùn)維時(shí)，比如服務(wù)治理、資源調(diào)度、服務(wù)安全管控等等，每一項(xiàng)服務(wù)甚至每一種方法都受監(jiān)控。方法是最小級(jí)別的調(diào)用和監(jiān)控對(duì)象。
性能參數(shù)采集分析，就是應(yīng)用和服務(wù)需要升級(jí)、改造或擴(kuò)容時(shí)，都是通過數(shù)據(jù)去支持。在傳統(tǒng)企業(yè)，應(yīng)用或服務(wù)的升級(jí)改造通常都是通過經(jīng)驗(yàn)判斷；在互聯(lián)網(wǎng)行業(yè)，大多都是通過數(shù)據(jù)去支撐判斷。
開發(fā)過程，從計(jì)劃、開發(fā)、編譯、測(cè)試、發(fā)布、實(shí)施、運(yùn)維，每個(gè)環(huán)節(jié)都有很多工具支撐。比如需求管理、開發(fā)階段。需求需要需求管理工具支持。開發(fā)階段可能需要：分布式數(shù)據(jù)庫、服務(wù)框架、開放平臺(tái)、分布式消息平臺(tái)、分布式緩存、統(tǒng)一ID生成器、SSO等等工具支撐，這些都是工具手段，在設(shè)計(jì)的時(shí)候可以根據(jù)場(chǎng)景去選型做取舍。比如在分布式的場(chǎng)景下，統(tǒng)一的ID生成器是否需要，依賴于我們的數(shù)據(jù)是否分片。為什么要統(tǒng)一ID？因?yàn)樵诜植际降捏w系中，無法知道ID在哪個(gè)數(shù)據(jù)片生成，需要統(tǒng)一的ID服務(wù)支撐，因?yàn)閿?shù)據(jù)是分片的，在各個(gè)數(shù)據(jù)片中存儲(chǔ)；應(yīng)用與應(yīng)用之間的集成大部分通過SSO完成；服務(wù)之間需要解耦，可能需要使用分布式消息平臺(tái)；提高服務(wù)的吞吐量可能需要分布式緩存；服務(wù)治理和管控在企業(yè)做微服務(wù)改造是必須的，不存在可能用或不可能用；開放平臺(tái)，一般來講是需要使用的。
分布式組件支撐詳解
基于PasS平臺(tái)，如自動(dòng)化運(yùn)維、分布式數(shù)據(jù)庫、消息緩存等，從整個(gè)信息流的過程來看，企業(yè)只需要關(guān)注應(yīng)用的開發(fā)、服務(wù)的開發(fā)、數(shù)據(jù)模型的設(shè)計(jì)開發(fā)；其他如自動(dòng)化的部署、數(shù)據(jù)分散等等。熱點(diǎn)數(shù)據(jù)放在緩存或搜索引擎中，這些都可以通過技術(shù)手段快速解決，只要對(duì)接API，將業(yè)務(wù)策略和業(yè)務(wù)機(jī)制制定好，就可以快速將數(shù)據(jù)進(jìn)行分散。在整個(gè)業(yè)務(wù)流的體系中，更多關(guān)注的是業(yè)務(wù)開發(fā)，技術(shù)由技術(shù)平臺(tái)去實(shí)現(xiàn)支撐和管控即可。
敏捷實(shí)現(xiàn)是關(guān)鍵
敏捷開發(fā)與傳統(tǒng)開發(fā)的對(duì)比，在微服務(wù)體系，按照傳統(tǒng)的開發(fā)模式是很難進(jìn)行開發(fā)的。在傳統(tǒng)模式下，假設(shè)項(xiàng)目的完成周期一般是3至6個(gè)月，但在實(shí)際開發(fā)過程中，可能會(huì)由于需求的變化而導(dǎo)致項(xiàng)目周期長達(dá)1年甚至1年以上，項(xiàng)目開發(fā)一半時(shí)，可能會(huì)出現(xiàn)30%的需求都發(fā)生改變，導(dǎo)致甲方、乙方或業(yè)務(wù)方和技術(shù)方一直在相互指責(zé)，一直沒有好的方法去解決，核心問題需求確實(shí)是一直在變化的。在敏捷開發(fā)模式下，只要將端到端的流程找出來，業(yè)務(wù)流程開發(fā)完成，在后續(xù)整個(gè)業(yè)務(wù)迭代的過程中，再逐步去完善。在進(jìn)行第一個(gè)迭代時(shí)就考慮下一個(gè)需求。在業(yè)務(wù)變化越來越頻繁、企業(yè)系統(tǒng)越來越開放的情況下，開發(fā)模式必須要進(jìn)行轉(zhuǎn)變，傳統(tǒng)的流程已經(jīng)無法適應(yīng)互聯(lián)網(wǎng)模式的快速迭代。
問答篇
CIO：如何理解微服務(wù)、中臺(tái)和SOA的關(guān)系？
柳杰：微服務(wù)、中臺(tái)和SOA實(shí)際上是三個(gè)層面上的問題。微服務(wù)是解決一個(gè)領(lǐng)域里的服務(wù)問題；SOA是解決公司層面業(yè)務(wù)服務(wù)的問題，二者不在一個(gè)層級(jí)上。微服務(wù)更多關(guān)注的是服務(wù)能力、業(yè)務(wù)的靈活性以及變更；SOA是解決服務(wù)治理、服務(wù)管控、服務(wù)的重用、企業(yè)業(yè)務(wù)資產(chǎn)問題。雖然微服務(wù)和SOA都有服務(wù)的治理和管控，在技術(shù)上有一定的相識(shí)度，但二者的服務(wù)粒度不在一個(gè)層級(jí)、服務(wù)的對(duì)象不一樣，微服務(wù)支撐SOA服務(wù)，SOA服務(wù)支撐應(yīng)用。中臺(tái)就是包含微服務(wù)和SOA，上層是SOA服務(wù)，下層是微服務(wù)，構(gòu)建起來就是一個(gè)中臺(tái)體系。
CIO：技術(shù)與業(yè)務(wù)分離，那么技術(shù)設(shè)計(jì)是按照什么思路來抽象化復(fù)雜業(yè)務(wù)的？
柳杰：業(yè)務(wù)很多時(shí)候是關(guān)注業(yè)務(wù)本身，業(yè)務(wù)流程的開發(fā)。在傳統(tǒng)企業(yè)中，業(yè)務(wù)開發(fā)的技術(shù)人員和技術(shù)工具開發(fā)的技術(shù)人員都是一波人，在應(yīng)用設(shè)計(jì)的時(shí)候，把兩種混在一起，把兩種技術(shù)人員混在一起。很難跳出這個(gè)圈子考慮問題。如剛才講的購物車?yán)?，無論誰開發(fā)購物車從業(yè)務(wù)功能上看都差不多，為什么大型互聯(lián)網(wǎng)公司設(shè)計(jì)的購物車可支持一億人同時(shí)在線，這實(shí)際上就是抓住技術(shù)支撐的特點(diǎn)，技術(shù)為業(yè)務(wù)服務(wù)賦能，在業(yè)務(wù)設(shè)計(jì)時(shí)讓服務(wù)與資源能夠多疊加。這是很關(guān)鍵的問題，如果這一問題沒有解決，仍要堅(jiān)持將技術(shù)與業(yè)務(wù)捆綁在一起開發(fā)，那么越開發(fā)，這個(gè)問題就會(huì)越來越復(fù)雜。
CIO：目前你們所改造的業(yè)務(wù)平臺(tái)，原來的平臺(tái)主要表現(xiàn)有哪些問題？
柳杰：主要有兩個(gè)方面的問題，一是系統(tǒng)的服務(wù)能力不夠。比如訂單量達(dá)到上萬的時(shí)候，這個(gè)平臺(tái)經(jīng)常會(huì)卡頓，或者用戶一擁上來就卡頓。二是業(yè)務(wù)與IT之間或產(chǎn)品之間經(jīng)常產(chǎn)生矛盾。比如業(yè)務(wù)提出的要求，IT很難支持，系統(tǒng)會(huì)出現(xiàn)不穩(wěn)定狀態(tài)。
幫助企業(yè)改造一個(gè)將原有系統(tǒng)替換掉的企業(yè)中臺(tái)，在完成B2B的交互后，企業(yè)可以基于這個(gè)中臺(tái)，自己構(gòu)建B2C或O2O的場(chǎng)景。系統(tǒng)能力問題、業(yè)務(wù)靈活問題、二開難度大等都是原來平臺(tái)主要存在的問題。
CIO：阿里、京東中臺(tái)有無實(shí)質(zhì)性區(qū)別？
柳杰：這兩個(gè)平臺(tái)在很早的時(shí)候就在構(gòu)建中臺(tái)，當(dāng)時(shí)沒有中臺(tái)這個(gè)概念，叫單元化改造或業(yè)務(wù)能力的升級(jí)支持，本質(zhì)上是IT系統(tǒng)與資源的疊加。實(shí)際上在資源進(jìn)行擴(kuò)展的時(shí)候，整個(gè)IT系統(tǒng)的能力也在提升。
CIO：實(shí)施阿里業(yè)務(wù)中臺(tái)和數(shù)據(jù)中臺(tái)有無注意事項(xiàng)？
柳杰：這是個(gè)核心問題。是否建立中臺(tái)，主要看兩個(gè)問題，一是解決業(yè)務(wù)的靈活性問題；二是解決業(yè)務(wù)的能力性問題。能力從傳統(tǒng)上來說就是增加垂直擴(kuò)展，如增加CPU、增加內(nèi)存的升級(jí)等等?；ヂ?lián)網(wǎng)公司是進(jìn)行水平的橫向擴(kuò)展，就是IT能與資源疊加。
實(shí)際上，中臺(tái)是屬于業(yè)務(wù)范疇的東西，將技術(shù)賦能業(yè)務(wù)的時(shí)候，業(yè)務(wù)能力是可以得到保障的。在實(shí)施中臺(tái)的時(shí)候，一定要將微服務(wù)與SOA的服務(wù)分開對(duì)待。微服務(wù)只是領(lǐng)域里的一個(gè)服務(wù)，服務(wù)力度僅限于業(yè)務(wù)領(lǐng)域，一定要識(shí)別領(lǐng)域。SOA化的業(yè)務(wù)服務(wù)范疇更大一點(diǎn)，這種服務(wù)可以是微服務(wù)的組合服務(wù)。
關(guān)于微服務(wù)與微服務(wù)之間的調(diào)用，微服務(wù)是在一個(gè)領(lǐng)域之內(nèi)，領(lǐng)域之內(nèi)的服務(wù)之間的調(diào)用，這種現(xiàn)象是存在的，但不多見，也不提倡。因此，在實(shí)施中臺(tái)時(shí)要充分考慮服務(wù)能力和業(yè)務(wù)能力靈活性這兩個(gè)問題，將這兩個(gè)問題解決后，后面實(shí)施業(yè)務(wù)中臺(tái)，這是業(yè)務(wù)領(lǐng)域拆分點(diǎn)，把業(yè)務(wù)領(lǐng)域、領(lǐng)域服務(wù)拆分出來，再把客流大的業(yè)務(wù)服務(wù)識(shí)別出來就可以了。
嘉賓簡介
柳杰，互聯(lián)網(wǎng)架構(gòu)資深專家，先后就職于京東、阿里等知名互聯(lián)網(wǎng)公司，經(jīng)歷了整個(gè)互聯(lián)網(wǎng)電子商務(wù)平臺(tái)的成長過程，作為互聯(lián)網(wǎng)資深架構(gòu)師，參與了互聯(lián)網(wǎng)架構(gòu)轉(zhuǎn)型的過程，深刻理解互聯(lián)網(wǎng)和互聯(lián)網(wǎng)交易平臺(tái)的架構(gòu)設(shè)計(jì)。對(duì)企業(yè)中臺(tái)化的改造有理論研究和實(shí)踐經(jīng)驗(yàn)，幫助多家企業(yè)成功實(shí)施企業(yè)中臺(tái)化改造，成功實(shí)現(xiàn)技術(shù)體系落地、業(yè)務(wù)靈活性設(shè)計(jì)和業(yè)務(wù)服務(wù)能力快速擴(kuò)展，實(shí)現(xiàn)業(yè)務(wù)場(chǎng)景快速開發(fā)和低成本試錯(cuò)，降低企業(yè)互聯(lián)網(wǎng)化改造的技術(shù)門檻和提高企業(yè)的業(yè)務(wù)快速響應(yīng)能力和業(yè)務(wù)創(chuàng)新能力。
聯(lián)系客服
