談到基礎(chǔ)架構(gòu)，不同的人有不同的理解。一般說來，我們將支撐應(yīng)用研發(fā)部署的底層軟硬件的集合叫做基礎(chǔ)架構(gòu)。它不僅涉及到IDC、機房、機架、網(wǎng)絡(luò)、主機、存儲等硬件資源，也涉及到操作系統(tǒng)、系統(tǒng)軟件、日志管理、應(yīng)用管理監(jiān)控等基礎(chǔ)軟件資源�；A(chǔ)架構(gòu)支持了分布式服務(wù)、大數(shù)據(jù)、云計算、機器學(xué)習(xí)等基礎(chǔ)領(lǐng)域，也成為IT類企業(yè)提升生產(chǎn)力、降低成本的核心。近些年來，隨著虛擬化、容器化等新技術(shù)的不斷涌現(xiàn)和發(fā)展，隨著應(yīng)用開發(fā)模式從單體應(yīng)用、MVC、SOA到微服務(wù)化，基礎(chǔ)架構(gòu)領(lǐng)域發(fā)生了翻天覆地的變化，其對應(yīng)用的靈活性和透明性不斷提升，也顯著提升了研發(fā)效率，降低了研發(fā)成本。
從IaaS、PaaS到CaaS
IaaS
基礎(chǔ)架構(gòu)涉及IDC、機房、網(wǎng)絡(luò)、主機等基礎(chǔ)資源、機架設(shè)計和交付、網(wǎng)絡(luò)架構(gòu)設(shè)計、數(shù)據(jù)架構(gòu)規(guī)劃、操作系統(tǒng)、系統(tǒng)軟件、環(huán)境交付和機器報廢替換等。早期應(yīng)用的開發(fā)和部署過程中大部分的工作不是關(guān)注于應(yīng)用的研發(fā)，而是關(guān)注于基礎(chǔ)環(huán)境的搭建，包括租用或者購買主機、搭建網(wǎng)絡(luò)設(shè)施、部署系統(tǒng)及日志監(jiān)控等基礎(chǔ)軟件。其開發(fā)部署效率低，整體成本高。IaaS基于虛擬化技術(shù)提供一種“隨需應(yīng)變”使用硬件資源的方式，它同時提供訪問物理主機、存儲和網(wǎng)絡(luò)硬件等接口，使得用戶能夠按需創(chuàng)建其需要的虛擬資源，較精細的控制所需的主機資源。通過IaaS，能夠屏蔽物理硬件的位置，同時節(jié)省了IDC、網(wǎng)絡(luò)、服務(wù)器的維護成本。相較于傳統(tǒng)的基礎(chǔ)架構(gòu)，IaaS對應(yīng)用研發(fā)人員提供了一層透明性。然而，IaaS仍是以資源為中心的，IaaS僅通過虛擬機提供了機器等底層硬件資源層級的抽象，虛擬機之上的操作系統(tǒng)，應(yīng)用軟件等都依賴于研發(fā)人員自行部署和維護。雖然IaaS擴容相對容易，但研發(fā)人員仍需從架構(gòu)上考慮機器宕機、機器故障、網(wǎng)絡(luò)故障等諸多因素，從而保障應(yīng)用的高可用。
PaaS
雖然Iaas通過虛擬化屏蔽了底層硬件資源，然而，對于應(yīng)用研發(fā)來說，還有很多基礎(chǔ)性的問題沒有解決，比如應(yīng)用部署、彈性擴縮容、高可用保障、監(jiān)控、日志等。因此，PaaS應(yīng)運而生。PaaS在IaaS的基礎(chǔ)上構(gòu)建了一層中間層，提供了完整的應(yīng)用開發(fā)、部署、運行、監(jiān)控平臺，提供了一系列的基礎(chǔ)服務(wù)：包括緩存服務(wù)、數(shù)據(jù)庫服務(wù)等。國內(nèi)外比較流行的PaaS平臺包括Amazon Web Service、Google App Engine、阿里云、騰訊云等。同時，PaaS平臺也提供了工具或者類庫來幫助研發(fā)人員創(chuàng)建應(yīng)用、訪問PaaS平臺提供的各種服務(wù)。PaaS平臺支持高可靠、自動擴縮容、故障遷移，運維成本極低，可以隨需滿足業(yè)務(wù)發(fā)展需求。相對于IaaS，PaaS平臺對應(yīng)用的支持更近了一步。然而，PaaS也存在缺點，主要體現(xiàn)在：
· 靈活性不夠
PaaS 提供的是應(yīng)用的開發(fā)、運行環(huán)境，用戶看不到底層虛擬機資源，因此一般無法對底層虛擬機資源進行控制。同時，PaaS平臺將應(yīng)用割裂成應(yīng)用代碼和基礎(chǔ)環(huán)境代碼（指應(yīng)用代碼所依賴的系統(tǒng)庫、運行環(huán)境、中間件等）。其中，基礎(chǔ)環(huán)境代碼基本上是固化和定制化的，由PaaS平臺提供。對于典型的PaaS平臺來說，不同的基礎(chǔ)環(huán)境需要提供不同的代碼，例如，Java、PHP、.NET等。應(yīng)用研發(fā)人員對基礎(chǔ)環(huán)境代碼沒有控制權(quán)，對PaaS平臺提供的基礎(chǔ)環(huán)境存在依賴，新的基礎(chǔ)環(huán)境需要平臺提供商提供后才能使用。例如，在PaaS平臺沒有提供Java 8的基礎(chǔ)環(huán)境之前，應(yīng)用研發(fā)人員是無法使用Java 8的。這限制了用戶的自主性和靈活性，在復(fù)雜場景中擴展性不足。
· 標(biāo)準(zhǔn)化程度不夠
一般說來，PaaS平臺都會對部署在其上的應(yīng)用提供一個強制性的約束規(guī)范，甚至?xí)峁┮恍┧接械腟DK供應(yīng)用來使用。同時，PaaS平臺提供的各類服務(wù)也是平臺私有的。當(dāng)應(yīng)用開發(fā)者使用此類私有的SDK和服務(wù)時，其適配成本較高，應(yīng)用侵入性強，同時其應(yīng)用會被PaaS平臺綁架，遷移成本很高。因此，PaaS平臺中的標(biāo)準(zhǔn)化問題非常重要。它不僅需要規(guī)范應(yīng)用部署和運行標(biāo)準(zhǔn)，還需要規(guī)范PaaS平臺提供的SDK和各種服務(wù)，從而減少甚至完全消除平臺對應(yīng)用的侵入性，降低應(yīng)用的遷移成本。
標(biāo)準(zhǔn)化程度和靈活性不夠，限制了PaaS平臺的進一步廣泛使用。不過，雖然PaaS平臺未能夠被進一步廣泛使用，但是它是從“以資源為中心”到“以應(yīng)用為中心”的一次有效的嘗試。
CaaS
過去幾年間，容器化成為虛擬化之后的又一個技術(shù)趨勢。容器簡單、輕量，具備很強的可移植性，能更高效的利用資源，還能夠有效的解決基礎(chǔ)環(huán)境依賴問題，提高研發(fā)效率，降低研發(fā)成本。因此，容器以其構(gòu)建、分發(fā)和部署的簡易性成為基礎(chǔ)架構(gòu)中的關(guān)鍵技術(shù)。其中Docker已成為容器技術(shù)的事實標(biāo)準(zhǔn)。隨著Docker等容器技術(shù)的廣泛應(yīng)用，容器編排和管理也受到了越來越多的關(guān)注，涌現(xiàn)出了以Kubernetes為代表的開源生態(tài)和解決方案。它們試圖將目前“以資源為中心”的管理方式遷移到“以應(yīng)用為中心”的管理方式，并且試圖對應(yīng)用的基礎(chǔ)構(gòu)成組件（例如配置、服務(wù)、負載均衡等）進行標(biāo)準(zhǔn)化，從而獲得更好的可管理性。容器生態(tài)的持續(xù)發(fā)展使得CaaS（Containers as a service）平臺開始涌現(xiàn)。CaaS平臺是一種以容器為基礎(chǔ)的應(yīng)用部署、運行和管理的方式，其底層資源可以來自于云服務(wù)商，也可以來自于自建私有云。事實上，我們可以把CaaS平臺看成以容器作為應(yīng)用交付標(biāo)準(zhǔn)的PaaS平臺。相較于PaaS平臺，基于容器的CaaS平臺具備如下優(yōu)勢：
· 靈活性高
前面我們提到，應(yīng)用可以分為應(yīng)用代碼和基礎(chǔ)環(huán)境代碼。在PaaS平臺中，基礎(chǔ)環(huán)境代碼由PaaS平臺控制，而在CaaS平臺中，基礎(chǔ)環(huán)境代碼的控制權(quán)從平臺方轉(zhuǎn)移到了應(yīng)用研發(fā)人員手中，應(yīng)用研發(fā)人員可以自由的選擇、甚至是自行構(gòu)建基礎(chǔ)環(huán)境，而無需依賴于平臺端。同時，由于容器所需的資源可以更靈活的控制，同時可以通過Sidecar模式、代理模式、適配器模式、分散收集模式等基于容器的分布式系統(tǒng)中的設(shè)計模式進行組合，應(yīng)用的可組合性大大提高。因此，應(yīng)用逐步被拆解職責(zé)獨立的模塊，這樣單個模塊職責(zé)更單一，更易于開發(fā)和測試，這也間接促進的微服務(wù)的發(fā)展。容器編排工具提供了一系列手段來自動化的管理應(yīng)用依賴的其他相關(guān)資源（例如負載均衡，甚至是調(diào)度），其靈活性大大提高。
· 標(biāo)準(zhǔn)化程度較高
社區(qū)很早就意識到并且在積極解決容器技術(shù)的標(biāo)準(zhǔn)化的問題。標(biāo)準(zhǔn)化組織OCI（Open Container Initialtive）成立于2015年6月，它致力于制定并維護容器鏡像規(guī)范（Image Specification）和容器運行時規(guī)范（Runtime Specification），分別對應(yīng)應(yīng)用的構(gòu)建和應(yīng)用的運行標(biāo)準(zhǔn)，使得讓一個滿足容器鏡像規(guī)范的容器可以在滿足容器運行時規(guī)范的平臺之間進行遷移。同時，標(biāo)準(zhǔn)化組織CNCF（Cloud Native Computing Foundation）也于2015年7月成立。 它主要關(guān)注容器的管理，它推出Cloud Native應(yīng)用，并期望定義能夠支持云原生應(yīng)用和容器的整個基礎(chǔ)設(shè)施標(biāo)準(zhǔn)，包括容器管理標(biāo)準(zhǔn)、監(jiān)控標(biāo)準(zhǔn)、分布式追蹤標(biāo)準(zhǔn)等。PaaS平臺由于標(biāo)準(zhǔn)化問題而未能得到廣泛應(yīng)用，OCI和CNCF則從一定程度上完成了基于容器的應(yīng)用構(gòu)建、運行和管理的標(biāo)準(zhǔn)化問題，推動了CaaS的發(fā)展，促使基礎(chǔ)架構(gòu)往 “以應(yīng)用為中心”遷移。
“以應(yīng)用為中心”中的應(yīng)用
隨著基礎(chǔ)架構(gòu)的透明性不斷提升，研發(fā)人員越來越關(guān)注應(yīng)用構(gòu)建，而不是關(guān)注于應(yīng)用部署所依賴的基礎(chǔ)架構(gòu)。雖然基于容器的規(guī)范在一定程度保證了應(yīng)用運行環(huán)境的標(biāo)準(zhǔn)化，然而，應(yīng)用的開發(fā)、部署和管理仍然是一件特別復(fù)雜的事情，特別是在分布式環(huán)境中。
標(biāo)準(zhǔn)化&可移植性
OCI和CNCF定義了容器鏡像標(biāo)準(zhǔn)、容器運行時標(biāo)準(zhǔn)、云原生應(yīng)用等，使得基于容器的應(yīng)用具備一定的標(biāo)準(zhǔn)化和可移植性。然而，在實踐中受限于諸多因素，應(yīng)用的可移植性仍然較低。
平臺本身提供的功能會影響應(yīng)用的可移植性。容器給用戶的視圖就是一個操作系統(tǒng)，采用基于容器的方式來構(gòu)建應(yīng)用，整個應(yīng)用的堆棧（包括基礎(chǔ)環(huán)境）基本上都由開發(fā)者控制，因此CaaS平臺對應(yīng)用的侵入性大大降低。不過，監(jiān)控、日志、安全等平臺級的約束存在，還是對應(yīng)用有一定的侵入性的。例如，平臺為了完成日志收集，一般都會對應(yīng)用的日志有一些規(guī)范，比如日志路徑等。這些約束一般由平臺方給出，或者是由應(yīng)用研發(fā)人員通過某個管理界面進行配置。同時，容器運行時規(guī)范僅定義了運行標(biāo)準(zhǔn)容器的最低約束，一般來說，平臺在滿足容器運行時規(guī)范的基礎(chǔ)上，會提供了一系列擴展來提供增值服務(wù)。雖然應(yīng)用鏡像本身無需調(diào)整，但在應(yīng)用部署時卻需要根據(jù)提供商的不同而進行配置。例如，同樣是使用負載均衡，某平臺可能采用LVS服務(wù)，而另一個平臺采用Nginx，這些約束在不同的平臺可能存在差異，這顯然影響了應(yīng)用的可移植性。
同時，平臺提供的服務(wù)會影響應(yīng)用的可移植性。應(yīng)用是一個巨大的生態(tài)系統(tǒng)，應(yīng)用研發(fā)人員會不自覺的使用云服務(wù)商的提供的各類私有服務(wù)，因此存在被平臺綁定/鎖定的風(fēng)險，影響可移植性。
因此，標(biāo)準(zhǔn)化工作不僅包含容器鏡像的標(biāo)準(zhǔn)化和容器運行環(huán)境的標(biāo)準(zhǔn)化，也包括容器部署描述符的標(biāo)準(zhǔn)化，此描述符將描述平臺本身提供的功能（包括監(jiān)控、日志、分布式追蹤、容器運行環(huán)境擴展等）和平臺所提供的服務(wù)。通過容器部署描述符的標(biāo)準(zhǔn)化，可以在應(yīng)用部署描述中同時將應(yīng)用的監(jiān)控相關(guān)信息和日志相關(guān)信息描述好，在應(yīng)用部署的時候依據(jù)這些信息完成監(jiān)控和日志等相關(guān)平臺功能的初始化工作，使得應(yīng)用具備最大的可移植性。事實上，開源監(jiān)控平臺Prometheus就朝這個方向邁出了一步。
動態(tài)性
應(yīng)用由于擴縮容、故障遷移等特征可能會導(dǎo)致其IP和端口隨時發(fā)生變化，使得應(yīng)用拓撲結(jié)構(gòu)從原來的靜態(tài)結(jié)構(gòu)變成動態(tài)結(jié)構(gòu)。因此，基于容器的應(yīng)用具備較強的動態(tài)性，這對依賴于它的服務(wù)產(chǎn)生了較大的影響，影響服務(wù)發(fā)現(xiàn)、權(quán)限等應(yīng)用的方方面面。其中，最重要的是服務(wù)發(fā)現(xiàn)，它涉及到應(yīng)用與依賴于它的應(yīng)用的通信問題。為了有效的管理應(yīng)用之間的通信，一般我們采用反向代理和動態(tài)發(fā)布/發(fā)現(xiàn)機制。
在采用反向代理的方式中，一般通過Nginx等反向代理訪問應(yīng)用，應(yīng)用發(fā)布時通過某種手段動態(tài)更新此反向代理的upstream。此種方式能夠有效的屏蔽應(yīng)用的地址和端口，訪問者僅通過域名訪問即可。不過，由于反向代理的存在，訪問鏈路中多了一個節(jié)點，對應(yīng)用性能會有一定的影響，不適應(yīng)于需要高性能的應(yīng)用。反向代理一般用于向外部網(wǎng)絡(luò)發(fā)布應(yīng)用，而不是處理內(nèi)部應(yīng)用之間的網(wǎng)絡(luò)通信。
在動態(tài)發(fā)布/發(fā)現(xiàn)機制中，一般會將應(yīng)用的IP地址和訪問端口存儲于某個集中的位置，例如服務(wù)注冊中心，應(yīng)用在啟動的時候通過一定的機制來自動完成注冊。同時，也提供一個客戶端SDK來動態(tài)獲取和感知應(yīng)用地址和端口的變化，從而調(diào)整客戶端的行為。此類SDK一般會提供負載均衡、流量監(jiān)控、限流、熔斷等能力，例如Spring Cloud。然而，此類 SDK一般會綁定到特定語言，且對應(yīng)用有一定的侵入性。
對于應(yīng)用來說，我們期望有一種基礎(chǔ)架構(gòu)，能夠減少應(yīng)用的訪問鏈路、降低應(yīng)用的侵入性。2017年逐步成為熱點的Service Mesh 給了我們一個可能的解決方案。Service Mesh是一種基礎(chǔ)設(shè)施層服務(wù)，它專注于處理應(yīng)用間的通信，負責(zé)將應(yīng)用間的請求安全、快速、可靠地在服務(wù)間進行傳輸，它可以在不修改應(yīng)用的基礎(chǔ)上提供流量監(jiān)控、限流、熔斷甚至是灰度發(fā)布、分布式跟蹤等能力。一般說來，Service Mesh是一種網(wǎng)絡(luò)代理，通過Sidecar模式與應(yīng)用部署在一起，應(yīng)用無需感知其存在。相較于反向代理，其訪問鏈路中不會多出一個節(jié)點，更適應(yīng)于內(nèi)部應(yīng)用之間的網(wǎng)絡(luò)通信。同時，相較于動態(tài)發(fā)布/發(fā)現(xiàn)機制中所使用的SDK，它沒有綁定到特定語言，開發(fā)者無需關(guān)心由此帶來的復(fù)雜性以及引入的技術(shù)問題，對應(yīng)用沒有侵入性。在過去一年中，Service Mesh 已經(jīng)成為云原生技術(shù)棧中的關(guān)鍵組件，也涌現(xiàn)出了一些開源實現(xiàn)，例如Istio 、Linkerd、Conduit 。業(yè)界一些知名公司也開始使用 Service Mesh，如 PayPal、Lyft等。然而，Service Mesh仍是一個不成熟且快速演化的技術(shù)，在生產(chǎn)環(huán)境中還未得到大規(guī)模的驗證。
“一次編譯，多處運行”
“一次編譯，多處運行”是我們在Java世界中一直努力的夢想。事實上，雖然Java提供了統(tǒng)一的二進制編碼，但是多處運行卻會受制于環(huán)境的約束。我們可以將應(yīng)用看成代碼和配置的組合，配置包括應(yīng)用配置和基礎(chǔ)環(huán)境配置。顯然，配置在不同的環(huán)境存在差異。在容器的世界要實現(xiàn)“一次編譯，多處運行”的夢想，我們需要很好的管理配置，而在應(yīng)用初始化時將配置推送到應(yīng)用端，從而實現(xiàn)配置即服務(wù)，通過配置屏蔽不同環(huán)境的差異。Kubernetes提供的ConfigMap、Spring Cloud Config、Consul等配置服務(wù)提供了這方面能力。然而，ConfigMap和Consul中存儲的配置信息是鍵值對，對于復(fù)雜的配置（例如文件類）支持不夠。 Spring Cloud Config雖然支持文件這類復(fù)雜配置，但是它無法應(yīng)用啟動前對基礎(chǔ)環(huán)境配置進行調(diào)整，例如，基于Tomcat的Web應(yīng)用的JVM參數(shù)。因此，為了達到“一次編譯，多處運行”，除了對應(yīng)用配置等進行管理之外，還需要額外提供基于環(huán)境的動態(tài)配置能力。
“以應(yīng)用為中心”中的基礎(chǔ)架構(gòu)
在應(yīng)用管理的整個生命周期中，一般會存在應(yīng)用研發(fā)者和平臺提供者，對于平臺提供者來說，它希望盡可能的將平臺功能和應(yīng)用的業(yè)務(wù)邏輯相隔離，盡可能減少對應(yīng)用開發(fā)者的約束。從應(yīng)用的開發(fā)模式來說，也經(jīng)歷了從單體應(yīng)用、客戶端-服務(wù)器端、多層應(yīng)用、服務(wù)化、微服務(wù)化的變遷，應(yīng)用研發(fā)過程也越來越傾向于單一職責(zé)，越來越聚焦于實際業(yè)務(wù)，而將安全、可靠性、性能、發(fā)布部署等職責(zé)交給基礎(chǔ)架構(gòu)。因此，基礎(chǔ)架構(gòu)發(fā)展一直持續(xù)不斷的往應(yīng)用方向延伸。在往“以應(yīng)用為中心”的遷移過程中，對基礎(chǔ)架構(gòu)提出了更多的要求：
· 基礎(chǔ)架構(gòu)的標(biāo)準(zhǔn)化：在大規(guī)模的實踐中，基礎(chǔ)架構(gòu)在應(yīng)用部署、灰度發(fā)布、資源調(diào)度、隔離性、運維監(jiān)控、日志、安全、管理等基礎(chǔ)性的能力仍有待進一步成熟和標(biāo)準(zhǔn)化。應(yīng)用可通過標(biāo)準(zhǔn)化的方式來描述其所需要的能力，基礎(chǔ)架構(gòu)則通過這些標(biāo)準(zhǔn)化的描述來為應(yīng)用配置日志、監(jiān)控、安全等，并執(zhí)行相應(yīng)的管理功能。
· 基礎(chǔ)架構(gòu)的應(yīng)用管理能力：基礎(chǔ)架構(gòu)應(yīng)該可以管理服務(wù)、任務(wù)、大數(shù)據(jù)平臺和算法框架等，通過提供通用的框架，降低相關(guān)組件、框架等的部署和優(yōu)化成本，廣泛支持在線服務(wù)、離線計算、流式計算、實時計算到算法決策等多種類型的業(yè)務(wù)。
· 基礎(chǔ)架構(gòu)的自管理能力：基礎(chǔ)架構(gòu)的穩(wěn)定性對于保證應(yīng)用的運行至關(guān)重要。除了對應(yīng)用進行管理之外，基礎(chǔ)架構(gòu)需對其自身的相關(guān)組件進行自我診斷、自我修復(fù)和自我優(yōu)化，使得其本身能夠保持健康的狀態(tài)。
· 動態(tài)資源分配和調(diào)整：提供自動化智能化的手段來管理并動態(tài)調(diào)整應(yīng)用所需的CPU、內(nèi)存等資源，使得應(yīng)用研發(fā)者將更多的精力關(guān)注應(yīng)用的業(yè)務(wù)研發(fā)，而不是應(yīng)用的性能優(yōu)化。同時，通過動態(tài)資源分配和調(diào)整機制，能夠幫助節(jié)省成本。
· 多環(huán)境管理：多環(huán)境管理不僅指私有數(shù)據(jù)中心、混和云等多個線上環(huán)境、也包括應(yīng)用的開發(fā)、測試環(huán)境。這些環(huán)境可能由不同云提供商提供，跨越多個地域，基礎(chǔ)架構(gòu)需要提供環(huán)境和地域感知的應(yīng)用部署和動態(tài)遷移，并盡可能的屏蔽不同環(huán)境的差異（例如，在測試環(huán)境中，會要求計算測試覆蓋率，線上環(huán)境則無此要求）。
總結(jié)
長久以來，應(yīng)用交付的核心訴求一直是更快的迭代速度、更快的開發(fā)效率、更高的易用性和可遷移性，更低的整體成本。從IaaS，PaaS到CaaS，我們逐步擺脫了對資源的關(guān)注，從不關(guān)注機房網(wǎng)絡(luò)機架等，到不關(guān)注應(yīng)用所使用的資源的物理位置。虛擬化、容器化和云計算等技術(shù)演進使得應(yīng)用研發(fā)和基礎(chǔ)架構(gòu)兩個方向越來越獨立，耦合性越來越低，促進其從“以資源為中心”往“以應(yīng)用為中心”遷移。其中，基礎(chǔ)架構(gòu)負責(zé)管理應(yīng)用的生命周期，管控應(yīng)用的部署、發(fā)布、日志、監(jiān)控、動態(tài)擴縮容，應(yīng)用依賴、應(yīng)用配置等，保障應(yīng)用的高可用、高性能，提高應(yīng)用對基礎(chǔ)架構(gòu)的透明性，提高基礎(chǔ)架構(gòu)的靈活性。
未來，應(yīng)用研發(fā)人員更關(guān)注于快速交付應(yīng)用，關(guān)注于應(yīng)用是否滿足其定義的SLA和成本等約束，聚焦于使用基礎(chǔ)架構(gòu)，而不用關(guān)注底層的基礎(chǔ)設(shè)施，不用關(guān)注應(yīng)用運行在Amazon Web Services或者是阿里云之上。也許有一天，我們僅需要關(guān)注應(yīng)用研發(fā)，而將包括主動性能優(yōu)化之內(nèi)的其他任何事情都交給基礎(chǔ)架構(gòu)。
咨詢熱線：0791-87557233
思誠者開發(fā)沙龍
贛公網(wǎng)安備 36010902000738號
贛ICP備17006097號-2 CopyRight©2014 - 2023
