第一部分：微服務(wù)的誕生、演變以及應(yīng)用策略

成都創(chuàng)新互聯(lián)主要從事成都網(wǎng)站制作、網(wǎng)站設(shè)計、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)平山,10年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18980820575

記者：近幾年來，微服務(wù)架構(gòu)設(shè)計方式被提出并在越來越多的企業(yè)中得以實踐和落地，但對于剛開始接觸微服務(wù)的人來說，還是不知道要從哪些方面開始了解。您能否結(jié)合軟件架構(gòu)的發(fā)展歷史，聊聊微服務(wù)的發(fā)展與特征。

梁鑫：微服務(wù)本質(zhì)上是一種架構(gòu)的風(fēng)格，如果要了解微服務(wù)，我認為需要先了解整個架構(gòu)的發(fā)展脈絡(luò)。

軟件架構(gòu)，總是在不斷的演進中。如果把時間退回到二十年前，當(dāng)時企業(yè)級領(lǐng)域研發(fā)主要推崇的還是C/S模式，PB、Delphi這樣的開發(fā)軟件是企業(yè)應(yīng)用開發(fā)的主流。

隨著時間的推移，我們發(fā)現(xiàn)標(biāo)準(zhǔn)化的客戶端存在一些弊病，比如我有一千個終端，升級版本需要每一臺終端都升級，這是非常麻煩的。然后，企業(yè)應(yīng)用研發(fā)開始向互聯(lián)網(wǎng)學(xué)習(xí)，把瀏覽器作為客戶端來使用，就可以避免這個問題。因此，基于瀏覽器的B/S架構(gòu)開始漸漸流行起來。

剛開始的時候是ASP，之后又出現(xiàn)了JSP，因為Ja.va的預(yù)編譯模式，讓性能有了非常大的提升，隨后基于Ja.va語言的J2EE架構(gòu)就變得越來越流行。至此，架構(gòu)經(jīng)歷了從傳統(tǒng)的C/S模式到B/S模式的轉(zhuǎn)變。

B/S架構(gòu)初期基本都是單體架構(gòu)，各個系統(tǒng)比較獨立，他們之間往往不需要進行交互，即使存在一些交互，也大多是數(shù)據(jù)層面的。那個階段ETL工具發(fā)展得很快，就是為了解決這樣的數(shù)據(jù)孤島問題。

隨著企業(yè)應(yīng)用越來越多，系統(tǒng)之間相互的關(guān)系也越來越密切，系統(tǒng)之間實時交互訪問的需求也越來越多。這個時候工程師們發(fā)現(xiàn)，不管是什么語言開發(fā)的軟件，基本都支持一種叫做XML的語言，于是提出一種實時交互的技術(shù)解決方案：通過XML語言來進行企業(yè)應(yīng)用系統(tǒng)之間的遠程調(diào)用。由此，SOA的概念被提了出來，WebService開始流行。

當(dāng)?shù)诙ɑヂ?lián)網(wǎng)浪潮來臨后，很多公司為了適應(yīng)更加靈活的業(yè)務(wù)發(fā)展，用基于HTTP協(xié)議和Restful的架構(gòu)風(fēng)格替代了原先笨重的WebService，簡潔清晰的JSON替代了XML。同時SOA架構(gòu)中常常采用服務(wù)總線技術(shù)，無疑是給系統(tǒng)架構(gòu)增加了一個異常麻煩的瓶頸。如果使用注冊和發(fā)現(xiàn)的機制，讓服務(wù)進程之間直接進行調(diào)用，更適合企業(yè)應(yīng)用的發(fā)展。這就是微服務(wù)架構(gòu)從技術(shù)方面來說的歷史脈絡(luò)。

在《微服務(wù)設(shè)計》中界定微服務(wù)有兩個基本原則：松耦合&高內(nèi)聚。即“把因相同因素變化的事情聚集在一起，把因不同因素變化的事情區(qū)隔開來。”至于微服務(wù)大小的劃分并沒有統(tǒng)一的標(biāo)準(zhǔn)，通俗地說，就是你覺得它的大小差不多，同時符合“松耦合&高內(nèi)聚”的原則就可以。

微服務(wù)有很多的好處，大致列舉一些。

• 異構(gòu)：微服務(wù)可以幫助我們輕松采用不同的技術(shù)，并且理解這些新技術(shù)的好處。嘗試新技術(shù)通常伴隨著風(fēng)險，但如果把服務(wù)切得很小了，總會存在一些點讓你可以選擇一個風(fēng)險最小的服務(wù)采用新技術(shù)，并降低風(fēng)險。
• 彈性：很明顯，微服務(wù)可以很好地處理服務(wù)不可用和功能降級的問題，因為它可以形成很多個節(jié)點。
• 隔離：微服務(wù)架構(gòu)將系統(tǒng)分解為獨立運行單元，給系統(tǒng)帶來更好的隔離性，獨立的微服務(wù)在發(fā)生異常時更容易定位和隔離問題，隔離性也是服務(wù)擴展性的基礎(chǔ)。
• 擴展：龐大的單體服務(wù)只能作為一個整體進行擴展，即使系統(tǒng)中只有一小部分模塊存在性能問題，也需要對整個系統(tǒng)進行擴展。而微服務(wù)架構(gòu)可以根據(jù)性能需要對不同的模塊進行水平擴展。
• 部署簡單：在微服務(wù)架構(gòu)中，各個服務(wù)的部署是獨立的，這樣就可以更快地對特定部分的代碼進行部署。服務(wù)出現(xiàn)問題也更容易快速回滾，同時敏捷的交付和部署帶來了更好的業(yè)務(wù)需求響應(yīng)體驗。
• 靈活：在微服務(wù)架構(gòu)中，系統(tǒng)會開放很多接口供外部使用，當(dāng)情況發(fā)生改變時，可以使用不同的方式構(gòu)建應(yīng)用。把單體應(yīng)用分解成多個微服務(wù)，可以達到可復(fù)用、可組合的目的。

記者：據(jù)悉，您之前發(fā)表過一篇文章“公司為什么需要建立一套統(tǒng)一的開發(fā)框架？”，您認為公司建立統(tǒng)一開發(fā)框架是為了解決什么問題？

梁鑫：這是一個仁者見仁智者見智的問題，每個人的出發(fā)點都不一樣，有的人可能主張需要統(tǒng)一，有的人則可能排斥統(tǒng)一，結(jié)合我的經(jīng)歷和實踐來看，我認為公司是需要建立統(tǒng)一開發(fā)框架的。

近十年，互聯(lián)網(wǎng)的發(fā)展顛覆了很多傳統(tǒng)行業(yè)，很多新興公司如雨后春筍般的冒了出來，它們的業(yè)務(wù)增長非?？?，公司規(guī)模也越來越大。這得益于中國經(jīng)濟的高速增長和互聯(lián)網(wǎng)的快速發(fā)展。但這種高速的發(fā)展過程中伴隨而來的是不可忽視的弊端：

• 弊端一：自我繁衍

在公司快速的發(fā)展過程中，往往會出現(xiàn)這樣一個鏈條。新增一塊業(yè)務(wù) —> 招聘一位高級技術(shù)人員 —> 圍繞這位同事組建一支技術(shù)團隊 —> 該業(yè)務(wù)基本由這只團隊負責(zé)，然后就形成了一個閉環(huán)。當(dāng)需要跟其他業(yè)務(wù)進行交互時，經(jīng)常是技術(shù)負責(zé)人之間自行決定。這就形成了自我繁衍的狀態(tài)。

• 弊端二：管控壁壘

隨著業(yè)務(wù)規(guī)模的快速發(fā)展，這個團隊很快形成了一個部門，團隊決策者通常會從自身利益考量，希望盡量減少對外部門的依賴，無論是技術(shù)選型、規(guī)范建立、組件選取、運行環(huán)境都能夠自行掌控。

• 弊端三：斷崖效應(yīng)

當(dāng)這樣的技術(shù)氛圍一旦形成，單個員工對單個項目的影響就會變的非常巨大。一個產(chǎn)品經(jīng)常會因為一兩個核心員工的離職難以為繼，最后不得不重新開發(fā)新的產(chǎn)品。

• 弊端四：資源浪費

當(dāng)每個團隊都在試圖構(gòu)建自己完整的研發(fā)流程時。中間的技術(shù)研究、產(chǎn)品研發(fā)、運維管理就會出現(xiàn)非常多的資源浪費。

• 弊端五：難以考核

怎么衡量一個川菜廚師和一個魯菜廚師誰更優(yōu)秀？當(dāng)每個團隊都是一個閉環(huán)，采用不同技術(shù)棧、不同的技術(shù)組件、不同的維護方式和規(guī)范時，已經(jīng)無法從產(chǎn)出效率來判斷一個團隊的績效，KPI 指標(biāo)也就非常難以設(shè)立。

建立一套公司級的統(tǒng)一的開發(fā)平臺可以有效解決上述問題。從技術(shù)層面來講，如果可以形成公司級別的統(tǒng)一開發(fā)平臺，會在實際的生產(chǎn)過程中帶來非常大的收益。

• 首先，避免了重復(fù)性技術(shù)研究，節(jié)約了人力成本。在項目組之下構(gòu)建一個基礎(chǔ)的開發(fā)架構(gòu)平臺，把技術(shù)共性問題提煉出來，交給一個專門團隊負責(zé)處理，讓項目組把精力投入到業(yè)務(wù)中。
• 其次，標(biāo)準(zhǔn)化了技術(shù)規(guī)范，提升了產(chǎn)品項目質(zhì)量。做工程要千人一面，而不要千人千面。采用統(tǒng)一的開發(fā)平臺后，在技術(shù)棧、技術(shù)組件、技術(shù)實現(xiàn)方案，甚至在代碼規(guī)范上，就能形成標(biāo)準(zhǔn)化的技術(shù)輸出模式，標(biāo)準(zhǔn)化帶來的效果不僅僅是開發(fā)效率的快速提升，還有產(chǎn)品質(zhì)量的大幅提升。
• 再次，可以進行技術(shù)沉淀，提升公司整體的技術(shù)能力，避免陷入一個人的能力決定一個項目。技術(shù)的進步來源于不斷的技術(shù)積累和沉淀，建立公司級別的統(tǒng)一開發(fā)框架（平臺），項目團隊基于該平臺進行自身項目的研發(fā)，不再需要關(guān)注于底層技術(shù)實現(xiàn)，只需要關(guān)注業(yè)務(wù)即可。而且，專注于平臺的同事為了更好地滿足項目組的技術(shù)需求，對平臺進行不斷的改進，從而達到技術(shù)積累和沉淀的目標(biāo)。
• 最后，可以對研發(fā)的投入和產(chǎn)出進行衡量，對研發(fā)團隊進行有效管理和考核。當(dāng)基于同一開發(fā)平臺的標(biāo)準(zhǔn)化技術(shù)規(guī)范建立起來后，對業(yè)務(wù)功能的代碼實現(xiàn)就可以進行相對有效的評估和考量，可以避免因為技術(shù)實現(xiàn)差異而出現(xiàn)的種種問題。這對KPI的制定和考核是一個巨大的幫助。

我從前年提出這樣的一個思想，通過一年多的努力，已經(jīng)在公司有了一定的成果。我們的統(tǒng)一開發(fā)平臺定位于技術(shù)層面，其主要目的是為統(tǒng)一公司內(nèi)相關(guān)產(chǎn)品研發(fā)和項目實施使用的技術(shù)架構(gòu)和開發(fā)工具，有效提高統(tǒng)一技術(shù)支持力度，形成持續(xù)的技術(shù)積累手段，提升技術(shù)人員的利用率并降低對人員的依賴性，最終提升軟件的規(guī)?；?、流水線式的生產(chǎn)能力。

記者：最近“Spring Boot”、“Spring Cloud”等詞總被提及，這些新的框架集合方案與傳統(tǒng)的微服務(wù)框架相比有哪些優(yōu)勢？結(jié)合您的經(jīng)驗來看，您認為微服務(wù)未來的發(fā)展走向可能是什么？

梁鑫：我是公司內(nèi)部較早研究Spring Cloud 技術(shù)棧的人，也是Spring Cloud中國社區(qū)的成員。Spring Cloud是在2017年一躍成為最流行的微服務(wù)開發(fā)框架。但是，這里有一個需要辯證看待的問題?！安皇钦f使用了Spring Cloud框架就實現(xiàn)了微服務(wù)架構(gòu)，具備了微服務(wù)架構(gòu)的優(yōu)勢”，正確的理解應(yīng)該是“使用Spring Cloud框架開發(fā)微服務(wù)架構(gòu)系統(tǒng)，使系統(tǒng)具備微服務(wù)架構(gòu)的優(yōu)勢?！?/p>

Spring Cloud之所以能從其他框架中脫穎而出成為最火的框架，得益于其本身體系的完整性。這一點通過下圖Spring Cloud、Dubbo和ServiceComb的對比可以比較直觀地了解到。

另外，Spring在中國有廣泛的群眾基礎(chǔ)，我也比較推崇這種“約定大于配置”的研發(fā)思想，不需要完全依賴標(biāo)準(zhǔn)化的東西。

我不敢妄談微服務(wù)架構(gòu)的未來走向。立足當(dāng)下，我認為目前Spring Cloud+Docker容器化的技術(shù)是用于微服務(wù)架構(gòu)的一個比較好的選擇。我比較認可一個很有趣的說法是“基因架構(gòu)”，意思是：架構(gòu)從誕生之初就是為了改變的，所以你的架構(gòu)越容易改變就越好。我覺得架構(gòu)的未來會向這條路發(fā)展。

我們的統(tǒng)一開發(fā)平臺的建設(shè)就是基于Spring Cloud技術(shù)棧。

記者：今年在軟件研發(fā)行業(yè)比較熱門的話題是“中臺”，在架構(gòu)層面也有人提出來要做微服務(wù)中臺，對此您怎么看？

梁鑫：去年一個綜藝節(jié)目帶火了一句話，“盤它”。節(jié)目里有一句 “干干巴巴的，麻麻賴賴的，一點都不圓潤，盤他！”。 后來說到什么就盤什么，也不管是什么東西，能不能握在手中，反正盤就是了。聽起來是不是特別有魔性，然后就有了“萬物皆可盤”這個段子。這本身其實只是一種調(diào)侃的講法，也并不會真的有人看到什么就盤什么。有意思的是任何事情都可以再認真往深處想一想，你會不會也犯一些看似荒唐的錯誤呢？

今年技術(shù)圈最火的一個名詞就是“中臺”，套用到這兒就變成了“萬物皆可中臺”，一個名詞到處套，我認為很多公司應(yīng)該避免盲目跟風(fēng)，讓“中臺”成為名詞陷阱。

面對一個新的技術(shù)或趨勢，我們要先了解其來源和根本。中臺的來源需要回溯到阿里。2015年阿里巴巴集團啟動了中臺戰(zhàn)略，目標(biāo)是要構(gòu)建符合互聯(lián)網(wǎng)大數(shù)據(jù)時代的，具有創(chuàng)新性、靈活性的‘大中臺、小前臺’的機制，即作為前臺的一線業(yè)務(wù)會更敏捷、更快速地適用瞬息萬變的市場，而中臺將集合整個集團的運營數(shù)據(jù)能力、產(chǎn)品技術(shù)能力，對各前臺業(yè)務(wù)形成強有力的支撐.

那阿里集團為什么要建立一個‘大中臺、小前臺’的架構(gòu)呢？《企業(yè)IT架構(gòu)轉(zhuǎn)型之道——阿里巴巴中臺戰(zhàn)略思考與架構(gòu)實戰(zhàn)》一書對此有詳細介紹。從阿里共享業(yè)務(wù)事業(yè)部的發(fā)展史說起，起初，阿里只有一個淘寶事業(yè)部，后來成立了天貓事業(yè)部，此時淘寶的技術(shù)團隊同時支撐著這兩個事業(yè)部。當(dāng)時的淘寶和天貓的電商系統(tǒng)像我們很多大型企業(yè)的一樣是分為兩套獨立的煙囪式體系，兩套體系中都包含的有商品、交易、支付、評價、物流等功能。因為上述原因，阿里集團又成立了共享業(yè)務(wù)事業(yè)部，其成員主要來自之前的淘寶技術(shù)團隊，同時將兩套電商業(yè)務(wù)做了梳理和沉淀，將兩個平臺中公共的、通用的業(yè)務(wù)功能沉淀到共享事業(yè)部，避免重復(fù)建設(shè)和維護。

作為一個擁有10多年編程經(jīng)驗的老兵，我經(jīng)常思考的一個問題就是系統(tǒng)發(fā)展的規(guī)律，透過其形領(lǐng)會其意，回顧架構(gòu)的發(fā)展，我認為可以總結(jié)出一點：“快”。當(dāng)然這個快是有前提的，比如正確率、資源限制，要在穩(wěn)定、盡量減少資源消耗的情況下求快。

“快”可以再次分解，從開發(fā)的角度來看，編寫代碼要快、開發(fā)要快、功能測試要快、環(huán)境部署要快、服務(wù)啟停要快；從生產(chǎn)的角度來看，程序運行的速度要快、高并發(fā)之下還是要快等。

微服務(wù)架構(gòu)之所以流行，因為把服務(wù)拆小了，可以高度復(fù)用，不用經(jīng)常編寫和修改代碼，節(jié)省了非常多的時間；容器化技術(shù)之所以流行，因為容器化技術(shù)可以使得生產(chǎn)環(huán)境和測試環(huán)境一致，節(jié)省了大量的環(huán)境部署時間、減少了出錯的可能性，還可以隨意增加容器節(jié)點，增強業(yè)務(wù)處理能力，保證高并發(fā)下的快速響應(yīng)。分布式架構(gòu)也是如此，微服務(wù)架構(gòu)其實就是分布式架構(gòu)的一種演化。萬變不離其宗，都是追求“快”。

回到“中臺”這個話題，建設(shè)中臺的目標(biāo)是避免重復(fù)建設(shè)和維護，快速響應(yīng)需求。后臺和平臺的系統(tǒng)比較穩(wěn)定，一般不輕易發(fā)生變化，而且從穩(wěn)定性考慮，應(yīng)該盡量減少后臺和平臺系統(tǒng)更新的次數(shù)，前端系統(tǒng)因為要適用用戶的需求而不斷變化，這樣前臺和后臺在對接時就產(chǎn)生了一個求變一個求不變的矛盾，這時我們希望在兩者之間建立一個中間平臺，把前端后臺可重復(fù)利用的東西集中到這個中間平臺來，重新封裝組合對外提供服務(wù)，這是符合“快”的思想的。

這是中臺的來源和根本，企業(yè)在建設(shè)中臺之前，一定要先了解這些，看所要建設(shè)的中臺是否符合“避免重復(fù)建設(shè)和維護”的思想，是否符合“快”的原則。

第二部分：微服務(wù)在業(yè)務(wù)中的應(yīng)用需要解決的關(guān)鍵問題

記者：宜信在今年開源了微服務(wù)任務(wù)調(diào)度平臺SIA-TASK，這個平臺在宜信技術(shù)團隊內(nèi)部有廣泛的應(yīng)用，開源后也得到了很多開發(fā)者的支持。您能否介紹一下這個平臺的設(shè)計思路以及核心功能？（設(shè)計開發(fā)這個平臺想要解決什么問題）

梁鑫：前面談到中臺，其實我認為“中臺”只是一個名稱而已，只要符合“避免重復(fù)建設(shè)和維護”和“快”兩個原則，叫什么都可以，比如我們的微服務(wù)調(diào)度平臺SIA-TASK，就是一個很像中臺的系統(tǒng)。

介紹SIA-TASK的設(shè)計思想之前，我先介紹一下它的背景。無論是互聯(lián)網(wǎng)應(yīng)用或者企業(yè)級應(yīng)用，都充斥著大量的批處理任務(wù)。常常需要一些任務(wù)調(diào)度系統(tǒng)幫助開發(fā)者解決問題。隨著微服務(wù)化架構(gòu)的逐步演進，單體架構(gòu)逐漸演變?yōu)榉植际健⑽⒎?wù)架構(gòu)。很多原先的任務(wù)調(diào)度平臺已經(jīng)不能滿足業(yè)務(wù)系統(tǒng)的需求，于是出現(xiàn)了一些基于分布式的任務(wù)調(diào)度平臺。這些平臺各有其特點，也各有不足之處，比如不支持任務(wù)編排、與業(yè)務(wù)高耦合、不支持跨平臺等問題，不符合新一代微服務(wù)架構(gòu)的需求，因此我們開發(fā)了微服務(wù)任務(wù)調(diào)度平臺（SIA-TASK）。

SIA-TASK 使用 SpringBoot 體系作為架構(gòu)選型，基于Quartz及Zookeeper進行二次開發(fā)，支持相應(yīng)的功能，SIA-TASK 的邏輯架構(gòu)圖如下圖所示：

SIA-TASK是任務(wù)調(diào)度平臺的一站式解決方案，契合當(dāng)前微服務(wù)架構(gòu)模式，具有跨平臺，可編排，高可用，無侵入，一致性，異步并行，動態(tài)擴展，實時監(jiān)控等特點。

了解任務(wù)調(diào)度平臺，需要先了解任務(wù)調(diào)度。任務(wù)大致分為三種，定期執(zhí)行的任務(wù)；隔固定時間執(zhí)行但不可并發(fā)的任務(wù)；每隔固定時間執(zhí)行的但是可以并發(fā)的任務(wù)。任務(wù)之間還可能存在一些次序關(guān)系，比如：串行、并行、分支等。

當(dāng)我們進行任務(wù)調(diào)度的時候，常常會發(fā)生以下的一些問題。

• 遺忘，一個項目有跑批任務(wù)，項目下線后跑批流程還在繼續(xù)，直到產(chǎn)生的日志把磁盤空間占滿了才發(fā)現(xiàn)；
• 單點，某個項目的跑批流程一直單點，機器故障后，流程停止運行；
• 依賴，某個項目的跑批流程A和B有依賴關(guān)系，只能設(shè)置兩個任務(wù)的時間錯開，如果發(fā)生A延時，需要手工處理出錯數(shù)據(jù)。

我們在設(shè)計SIA-TASK的時候，將平臺和項目組運行割裂開來。SIA-TASK包括五大模塊，任務(wù)執(zhí)行器，即真正業(yè)務(wù)邏輯需要跑批的業(yè)務(wù)，屬于項目組，項目組在啟動的時候會把執(zhí)行的任務(wù)暴露成一個服務(wù)，這個服務(wù)注冊到任務(wù)注冊中心來；任務(wù)注冊中心拿到一個任務(wù)，并將它存儲到持久存儲的數(shù)據(jù)庫里，同時進行編排，編排成有依賴關(guān)系的任務(wù)；最后任務(wù)調(diào)度中心拿到任務(wù)編排中心里已經(jīng)編排好的需要執(zhí)行的任務(wù)，進行遠程調(diào)用。

在整個過程中，任務(wù)調(diào)度、編排、執(zhí)行與項目組是分開的，項目組只需要關(guān)心任務(wù)調(diào)度的業(yè)務(wù)邏輯代碼，剩下的都在SIA-TASK平臺執(zhí)行，相當(dāng)于把每個項目任務(wù)都原子化了，都變成了一個個微服務(wù)。

只把業(yè)務(wù)邏輯留在項目組，調(diào)度、編排、執(zhí)行歸類到平臺中，所有需要代碼處理的東西都通過配置化的方式實現(xiàn)，也符合中臺“避免重復(fù)建設(shè)的維護”的思想。

SIA-TASK目前已經(jīng)開源，具體的設(shè)計思想和功能以及部署操作可以在GitHub查看，地址：?https://github.com/siaorg/sia-task

記者：微服務(wù)任務(wù)調(diào)度平臺（SIA-TASK）適用于哪些場景?

梁鑫：SIA-TASK是基于HTTP協(xié)議的進行遠程調(diào)度的，實際業(yè)務(wù)中高并發(fā)的調(diào)度處理支持肯定是不夠理想的。如果業(yè)務(wù)是高并發(fā)的、每秒鐘需要喚醒幾千幾萬個任務(wù)的場景就不太適合使用SIA-TASK。除此之外，其他所有場景幾乎都可使用SIA-TASK。

當(dāng)前名稱：回歸架構(gòu)本質(zhì)，重新理解微服務(wù)
分享鏈接：http://jinyejixie.com/article18/gdjgdp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網(wǎng)站、網(wǎng)站設(shè)計公司、動態(tài)網(wǎng)站、網(wǎng)站改版、品牌網(wǎng)站建設(shè)、用戶體驗

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)