基于SpringCloud-微服務(wù)系統(tǒng)設(shè)計(jì)方案【實(shí)用文檔】doc

基于SpringCloud-微服務(wù)系統(tǒng)設(shè)計(jì)方案【實(shí)用文檔】doc文檔可直接使用可編輯，歡迎下載

微服務(wù)系統(tǒng)設(shè)計(jì)方案基于SpringCloud-微服務(wù)系統(tǒng)設(shè)計(jì)方案【實(shí)用文檔】doc文檔可直接使用可編輯，歡迎下載微服務(wù)本質(zhì) 微服務(wù)架構(gòu)從本質(zhì)上說(shuō)其實(shí)就是分布式架構(gòu),與其說(shuō)是一種新架構(gòu)，不如說(shuō)是一種微服務(wù)架構(gòu)風(fēng)格。?簡(jiǎn)單來(lái)說(shuō),微服務(wù)架構(gòu)風(fēng)格是要開(kāi)發(fā)一種由多個(gè)小服務(wù)組成的應(yīng)用。每個(gè)服務(wù)運(yùn)行于獨(dú)立的進(jìn)程，并且采用輕量級(jí)交互.多數(shù)情況下是一個(gè)HTTP的資源AＰI.這些服務(wù)具備獨(dú)立業(yè)務(wù)能力并可以通過(guò)自動(dòng)化部署方式獨(dú)立部署。這種風(fēng)格使最小化集中管理，從而可以使用多種不同的編程語(yǔ)言和數(shù)據(jù)存儲(chǔ)技術(shù)。?對(duì)于微服務(wù)架構(gòu)系統(tǒng)，由于其服務(wù)粒度小，模塊化清晰，因此首先要做的是對(duì)系統(tǒng)整體進(jìn)行功能、服務(wù)規(guī)劃，優(yōu)先考慮如何在交付過(guò)程中，從工程實(shí)踐出發(fā)，組織好代碼結(jié)構(gòu)、配置、測(cè)試、部署、運(yùn)維、監(jiān)控的整個(gè)過(guò)程，從而有效體現(xiàn)微服務(wù)的獨(dú)立性與可部署性。 本文將從微服務(wù)系統(tǒng)的設(shè)計(jì)階段、開(kāi)發(fā)階段、測(cè)試階段、部署階段進(jìn)行綜合闡述。?理解微服務(wù)架構(gòu)和理念是核心。系統(tǒng)環(huán)境名稱(chēng)版本說(shuō)明ＪDK１。8SpringBoｏtＳprinｇＦrameｗｏrｋRibｂonkａfkaＲabｂiｔMQ微服務(wù)架構(gòu)的挑戰(zhàn)可靠性:由于采用遠(yuǎn)程調(diào)用的方式,任何一個(gè)節(jié)點(diǎn)、網(wǎng)絡(luò)出現(xiàn)問(wèn)題，都將使得服務(wù)調(diào)用失敗，隨著微服務(wù)數(shù)量的增多，潛在故障點(diǎn)也將增多。也就是沒(méi)有充分的保障機(jī)制,則單點(diǎn)故障會(huì)大量增加.運(yùn)維要求高: ?系統(tǒng)監(jiān)控、高可用性、自動(dòng)化技術(shù)分布式復(fù)雜性：??網(wǎng)絡(luò)延遲、系統(tǒng)容錯(cuò)、分布式事務(wù)部署依賴(lài)性強(qiáng):? 服務(wù)依賴(lài)、多版本問(wèn)題性能(服務(wù)間通訊成本高）:? 無(wú)狀態(tài)性、進(jìn)程間調(diào)用、跨網(wǎng)絡(luò)調(diào)用?數(shù)據(jù)一致性：? 分布式事務(wù)管理需要跨越多個(gè)節(jié)點(diǎn)來(lái)保證數(shù)據(jù)的瞬時(shí)一致性，因此比起傳統(tǒng)的單體架構(gòu)的事務(wù),成本要高得多。另外，在分布式系統(tǒng)中,通常會(huì)考慮通過(guò)數(shù)據(jù)的最終一致性來(lái)解決數(shù)據(jù)瞬時(shí)一致帶來(lái)的系統(tǒng)不可用。重復(fù)開(kāi)發(fā)： ?微服務(wù)理念崇尚每個(gè)微服務(wù)作為一個(gè)產(chǎn)品看待,有自己的團(tuán)隊(duì)開(kāi)發(fā)，甚至可以有自己完全不同的技術(shù)、框架，那么與其他微服務(wù)團(tuán)隊(duì)的技術(shù)共享就產(chǎn)生了矛盾，重復(fù)開(kāi)發(fā)的工作即產(chǎn)生了。?沒(méi)有最好的，只有最適合自己的。架構(gòu)設(shè)計(jì)思維設(shè)計(jì)?微服務(wù)架構(gòu)設(shè)計(jì)的根本目的是實(shí)現(xiàn)價(jià)值交付，微服務(wù)架構(gòu)只有遵循ＤevOps理念方可進(jìn)行的更順暢，思維方式的轉(zhuǎn)變是最重要的。實(shí)現(xiàn)微服務(wù)技術(shù)架構(gòu)，現(xiàn)有產(chǎn)品需要進(jìn)行技術(shù)上的改進(jìn)以及相關(guān)配套服務(wù)的實(shí)現(xiàn)，采用分階段實(shí)施、以及試點(diǎn)產(chǎn)品優(yōu)先實(shí)施的策略，主要包括如下：?一、技術(shù)上的改進(jìn):?1、前后端分離，web前端通過(guò)Hｔtｐ/Ｈttps協(xié)議調(diào)用微服務(wù)的APＩ網(wǎng)關(guān)，由AＰI網(wǎng)關(guān)再經(jīng)過(guò)路由服務(wù)調(diào)用相應(yīng)的微服務(wù)?２、不同微服務(wù)之間通過(guò)REＳT方式互相調(diào)用?3、微服務(wù)之間通過(guò)消息中間件實(shí)現(xiàn)消息交互機(jī)制?二、配套服務(wù)與功能實(shí)現(xiàn): 1、需要進(jìn)行相應(yīng)的自動(dòng)化服務(wù)實(shí)現(xiàn)，包括自動(dòng)化構(gòu)建、自動(dòng)化安裝部署、自動(dòng)化測(cè)試、自動(dòng)化平臺(tái)發(fā)布(Ｄｏｃker實(shí)現(xiàn)）?2、管理服務(wù)，對(duì)于微服務(wù)架構(gòu)，必須配套相應(yīng)的監(jiān)控與管理服務(wù)、日志管理服務(wù)等?３、協(xié)作服務(wù),運(yùn)用ＤeｖＯｐs思想提升開(kāi)發(fā)、測(cè)試、運(yùn)維的高效溝通與協(xié)作，實(shí)現(xiàn)開(kāi)發(fā)與運(yùn)維的一體化微服務(wù)架構(gòu)設(shè)計(jì)?

１、我們把整個(gè)系統(tǒng)根據(jù)業(yè)務(wù)拆分成若干個(gè)子系統(tǒng)或微服務(wù).

2、每個(gè)子系統(tǒng)可以部署多個(gè)應(yīng)用,多個(gè)應(yīng)用之間使用負(fù)載均衡。

３、需要一個(gè)服務(wù)注冊(cè)中心Eureka，所有的服務(wù)都在注冊(cè)中心注冊(cè)，負(fù)載均衡也是通過(guò)在注冊(cè)中心注冊(cè)的服務(wù)來(lái)使用一定策略來(lái)實(shí)現(xiàn)。? Euｒeka可部署多個(gè),進(jìn)行高可用保證。

4、所有的客戶(hù)端都通過(guò)同一個(gè)網(wǎng)關(guān)地址訪問(wèn)后臺(tái)的服務(wù)，通過(guò)路由配置ZＵＵＬ網(wǎng)關(guān)來(lái)判斷一個(gè)URL請(qǐng)求由哪個(gè)服務(wù)處理.請(qǐng)求轉(zhuǎn)發(fā)到服務(wù)上的時(shí)候使用負(fù)載均衡Ribbｏｎ。

5、服務(wù)之間采用feigｎ進(jìn)行調(diào)用.

6、使用斷路器hyｓtrix,及時(shí)處理服務(wù)調(diào)用時(shí)的超時(shí)和錯(cuò)誤，防止由于其中一個(gè)服務(wù)的問(wèn)題而導(dǎo)致整體系統(tǒng)的癱瘓。

7、還需要一個(gè)監(jiān)控功能，監(jiān)控每個(gè)服務(wù)調(diào)用花費(fèi)的時(shí)間等.8、使用SpringＣloudＣｏnfiｇ進(jìn)行統(tǒng)一的配置管理，需要考慮與公司的配置管理平臺(tái)如何配合使用。?９、Hyｓｔriｘ，監(jiān)控和斷路器.我們只需要在服務(wù)接口上添加Hｙsｔrix標(biāo)簽，就可以實(shí)現(xiàn)對(duì)這個(gè)接口的監(jiān)控和斷路器功能。

10、HystrixDａshboaｒd,監(jiān)控面板，他提供了一個(gè)界面,可以監(jiān)控各個(gè)服務(wù)上的服務(wù)調(diào)用所消耗的時(shí)間等。

11、Tｕrbiｎe，監(jiān)控聚合，使用Hystｒｉx監(jiān)控,我們需要打開(kāi)每一個(gè)服務(wù)實(shí)例的監(jiān)控信息來(lái)查看。而Tｕrbine可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個(gè)地方統(tǒng)一查看。這樣就不需要挨個(gè)打開(kāi)一個(gè)個(gè)的頁(yè)面一個(gè)個(gè)查看。架構(gòu)的可靠性保證:?在關(guān)鍵節(jié)點(diǎn)做主備、集群部署,防止單點(diǎn)故障.待后續(xù)確認(rèn)問(wèn)題： １、AcｃessＣontrol：Zuｕl網(wǎng)關(guān)提供了相關(guān)控制功能，與我司ＣAS如何結(jié)合使用?2、ConｆigＳｅrver:ＳprinｇCloud提供了遠(yuǎn)程配置中心，與我司的配置管理平臺(tái)如何結(jié)合使用設(shè)計(jì)階段總體設(shè)計(jì) 1、功能規(guī)劃：對(duì)產(chǎn)品功能進(jìn)行拆分，拆分為若干個(gè)微服務(wù)；一個(gè)功能可以創(chuàng)建多個(gè)微服務(wù)并部署在多個(gè)服務(wù)器節(jié)點(diǎn)上,以便進(jìn)行負(fù)載均衡。 2、設(shè)計(jì)原子服務(wù)層,梳理和抽取核心應(yīng)用、公共應(yīng)用，作為獨(dú)立的服務(wù)下沉到核心和公共能力層,逐漸形成穩(wěn)定的服務(wù)中心,使應(yīng)用能更快速的響應(yīng)多變的客戶(hù)需求。?3、為每個(gè)服務(wù)設(shè)計(jì)API接口(REST方式)?4、為不同的服務(wù)進(jìn)行分類(lèi)，不同類(lèi)型的服務(wù)需要的資源不同，可以配置不同的資源,包括CＰU、內(nèi)存、存儲(chǔ)等。服務(wù)拆分原則?1、粒度微小: ?根據(jù)業(yè)務(wù)功能劃分服務(wù)粒度，總的原則是服務(wù)內(nèi)部高內(nèi)聚，服務(wù)之間低耦合。?2、責(zé)任單一： 每個(gè)服務(wù)只做一件事，即單一職責(zé)原則。 ３、隔離性原則： ?每個(gè)服務(wù)相互隔離，且不互相影響?４、業(yè)務(wù)無(wú)關(guān)優(yōu)先原則: ?基礎(chǔ)服務(wù)，是一些基礎(chǔ)組件，與具體的業(yè)務(wù)無(wú)關(guān)。比如:短信服務(wù)、郵件服務(wù).這里的服務(wù)最容易劃分出來(lái)做微服務(wù)，也是我們第一優(yōu)先級(jí)分離出來(lái)的服務(wù)。服務(wù)規(guī)劃 為實(shí)現(xiàn)負(fù)載均衡，允許相同的服務(wù)在多個(gè)節(jié)點(diǎn)注冊(cè)相同的服務(wù)名，不同的端口.如果沒(méi)有前期的規(guī)劃，不同的服務(wù)提供者可能會(huì)注冊(cè)相同的服務(wù)名，導(dǎo)致消費(fèi)者調(diào)用服務(wù)時(shí)產(chǎn)生調(diào)用混亂。?因此，需進(jìn)行服務(wù)名的統(tǒng)一規(guī)劃: 1、規(guī)劃期統(tǒng)一制定每個(gè)服務(wù)提供者的服務(wù)名或者模塊標(biāo)示。?2、服務(wù)名的命名規(guī)則:ModuleＮaｍｅ_ＳeｒvｉｃeNamｅ，且所有字符小寫(xiě)，不同單詞之間以下劃線(xiàn)分隔。如用戶(hù)管理模塊提供了獲取用戶(hù)信息的服務(wù),則命名為：useｒ_ｇｅｔ＿info。?3、新增服務(wù)名時(shí)，需要提出申請(qǐng),審批通過(guò)后方可使用，為減少審批復(fù)雜度,可只審批ＭodｕleNａme,即在模塊內(nèi)部可以自由增加服務(wù)名,不需要進(jìn)行審批。開(kāi)發(fā)策略?總體原則：不同的微服務(wù)需進(jìn)行物理隔離。?１、ＳVN策略：ＳＶN上創(chuàng)建獨(dú)立的分支,不同微服務(wù)的代碼提交不受相互影響; —-—由配置管理員統(tǒng)一控制。 問(wèn)題:開(kāi)發(fā)分支與集成分支,都將增加很多,維護(hù)工作量增加. 2、編譯策略：代碼編譯時(shí)，各個(gè)微服務(wù)獨(dú)立編譯、打包,杜絕直接的依賴(lài)；?３、工程構(gòu)建：代碼開(kāi)發(fā)時(shí),各微服務(wù)創(chuàng)建獨(dú)立的工程,工程之間不能產(chǎn)生直接依賴(lài) ４、持續(xù)集成:每個(gè)微服務(wù)獨(dú)立執(zhí)行持續(xù)集成. 5、版本集成:由統(tǒng)一的集成工具，實(shí)現(xiàn)自動(dòng)化的版本集成,將所有微服務(wù)集成到統(tǒng)一的版本發(fā)布包中。版本策略?每個(gè)微服務(wù)可以獨(dú)立制作版本，伴隨著服務(wù)的增多，SVＮ分支增多,版本也將增多，版本管理的復(fù)雜度將成指數(shù)級(jí)增加。在服務(wù)之間依賴(lài)較多時(shí),每個(gè)服務(wù)的升級(jí)或降級(jí)都將影響其他服務(wù)的正常運(yùn)行。 因此需執(zhí)行如下策略： １、所有服務(wù)的版本制作交由專(zhuān)業(yè)的版本管理員執(zhí)行. 2、采用自動(dòng)化的版本制作策略，最大程度的減少人工操作.?３、每個(gè)服務(wù)的版本必須有詳細(xì)的版本計(jì)劃、版本說(shuō)明,對(duì)于版本說(shuō)明要制定模板，明確需要提交的內(nèi)容、版本號(hào)、SVN標(biāo)簽等。?4、對(duì)項(xiàng)目經(jīng)理的要求提升,需對(duì)整體的版本計(jì)劃有嚴(yán)格的制定，尤其是版本之間的依賴(lài)關(guān)系要非常明確,版本升級(jí)、降級(jí)的風(fēng)險(xiǎn)評(píng)估需完全充分. ５、接口管理：嚴(yán)格執(zhí)行接口管理制度,任何接口的變更必須進(jìn)行審批、發(fā)公告等流程。數(shù)據(jù)庫(kù)挑戰(zhàn)與策略 每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫(kù),那么后臺(tái)管理的聯(lián)合查詢(xún)?cè)趺刺幚?？這應(yīng)該是大家會(huì)普遍遇到的一個(gè)問(wèn)題,有三種處理方案。?1）嚴(yán)格按照微服務(wù)的劃分來(lái)做，微服務(wù)相互獨(dú)立,各微服務(wù)數(shù)據(jù)庫(kù)也獨(dú)立，后臺(tái)需要展示數(shù)據(jù)時(shí)，調(diào)用各微服務(wù)的接口來(lái)獲取對(duì)應(yīng)的數(shù)據(jù)，再進(jìn)行數(shù)據(jù)處理后展示出來(lái)，這是標(biāo)準(zhǔn)的用法，也是最麻煩的用法。?2)將業(yè)務(wù)高度相關(guān)的表放到一個(gè)庫(kù)中，將業(yè)務(wù)關(guān)系不是很緊密的表嚴(yán)格按照微服務(wù)模式來(lái)拆分,這樣既可以使用微服務(wù)，也避免了數(shù)據(jù)庫(kù)分散導(dǎo)致后臺(tái)系統(tǒng)統(tǒng)計(jì)功能難以實(shí)現(xiàn)，是一個(gè)折中的方案。?3)數(shù)據(jù)庫(kù)嚴(yán)格按照微服務(wù)的要求來(lái)切分，以滿(mǎn)足業(yè)務(wù)高并發(fā),實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)將各微服務(wù)數(shù)據(jù)庫(kù)數(shù)據(jù)同步到ＮoSQＬ數(shù)據(jù)庫(kù)中,在同步的過(guò)程中進(jìn)行數(shù)據(jù)清洗，用來(lái)滿(mǎn)足后臺(tái)業(yè)務(wù)系統(tǒng)的使用，推薦使用MｏｎgｏDB、ＨＢａse等。 第一種方案適合業(yè)務(wù)較為簡(jiǎn)單的小公司；第二種方案,適合在原有系統(tǒng)之上，慢慢演化為微服務(wù)架構(gòu)的公司；第三種適合大型高并發(fā)的互聯(lián)網(wǎng)公司。?建議，我們當(dāng)前采用第二種方案。負(fù)載均衡 不再采用一般的增加負(fù)載均衡服務(wù)器的方式進(jìn)行負(fù)載均衡，如F５、Ngｉｎx、LVＳ等，而是把負(fù)載均衡的功能以庫(kù)的方式集成到服務(wù)消費(fèi)方的進(jìn)程內(nèi),這種方案稱(chēng)為軟負(fù)載均衡（SoｆｔLoaｄＢalａnｃｉng)或者客戶(hù)端負(fù)載均衡.在SｐriｎgＣlｏuｄ中配合Euｒｅkａ的服務(wù)注冊(cè)功能，Ribbon子項(xiàng)目則為RＥST客戶(hù)端實(shí)現(xiàn)了負(fù)載均衡。?使用Ribｂｏｎ進(jìn)行負(fù)載均衡，其工作原理可以概括為下面四個(gè)步驟:Ribbon首先根據(jù)其所在Zoｎe優(yōu)先選擇一個(gè)負(fù)載較少的ＥuｒekaSeｒｖer；定期從EurekａServer更新并過(guò)濾服務(wù)實(shí)例列表;根據(jù)指定的負(fù)載均衡策略,從可用的服務(wù)器列表中選擇一個(gè)服務(wù)實(shí)例的地址;然后通過(guò)ReｓtClient進(jìn)行服務(wù)調(diào)用。Ｒibbon本身提供了下面幾種負(fù)載均衡策略:RoundＲobiｎRｕle:

輪詢(xún)策略，Ｒiｂｂon以輪詢(xún)的方式選擇服務(wù)器,這個(gè)是默認(rèn)值.所以示例中所啟動(dòng)的兩個(gè)服務(wù)會(huì)被循環(huán)訪問(wèn);RandomRule：

隨機(jī)選擇，也就是說(shuō)Ribｂｏn會(huì)隨機(jī)從服務(wù)器列表中選擇一個(gè)進(jìn)行訪問(wèn);ＢeｓtＡvaiｌablｅRｕｌe：

最大可用策略,即先過(guò)濾出故障服務(wù)器后，選擇一個(gè)當(dāng)前并發(fā)請(qǐng)求數(shù)最小的；WeightedRespｏnｓeＴｉｍeRｕle:

帶有加權(quán)的輪詢(xún)策略，對(duì)各個(gè)服務(wù)器響應(yīng)時(shí)間進(jìn)行加權(quán)處理，然后在采用輪詢(xún)的方式來(lái)獲取相應(yīng)的服務(wù)器;AvaｉｌabｉlityFｉlteringRulｅ：

可用過(guò)濾策略,先過(guò)濾出故障的或并發(fā)請(qǐng)求大于閾值一部分服務(wù)實(shí)例，然后再以線(xiàn)性輪詢(xún)的方式從過(guò)濾后的實(shí)例清單中選出一個(gè)；ZonｅAvoidaｎceRule：

區(qū)域感知策略,先使用主過(guò)濾條件(區(qū)域負(fù)載器，選擇最優(yōu)區(qū)域)對(duì)所有實(shí)例過(guò)濾并返回過(guò)濾后的實(shí)例清單,依次使用次過(guò)濾條件列表中的過(guò)濾條件對(duì)主過(guò)濾條件的結(jié)果進(jìn)行過(guò)濾，判斷最小過(guò)濾數(shù)（默認(rèn)1)和最小過(guò)濾百分比(默認(rèn)0）,最后對(duì)滿(mǎn)足條件的服務(wù)器則使用RｏｕnｄＲobinＲule（輪詢(xún)方式）選擇一個(gè)服務(wù)器實(shí)例。性能策略 １、網(wǎng)絡(luò)優(yōu)化:優(yōu)化組網(wǎng)結(jié)構(gòu)，提升網(wǎng)絡(luò)間通訊性能; 2、配置優(yōu)化：優(yōu)化SpriｎgCloud組件集以及其他組件的配置信息，使得性能最大化.技術(shù)管理策略?微服務(wù)的架構(gòu)理念中指出各微服務(wù)可以獨(dú)立建設(shè)，可以使用不同的技術(shù)、語(yǔ)言、框架等，以便能更快速的使用新技術(shù)、新框架等響應(yīng)特定客戶(hù)需求，解決單體應(yīng)用架構(gòu)更新技術(shù)、更新框架時(shí)面臨的困難或阻礙。?但這也同時(shí)帶來(lái)了諸多問(wèn)題，如下： 1、各服務(wù)是否可以任意使用自己的技術(shù)、自己的組件、框架呢？如果這樣，勢(shì)必帶來(lái)更大的管理困難、維護(hù)困難、技術(shù)共享困難。 2、公共的方法如何實(shí)現(xiàn)共享？如格式化時(shí)間的一個(gè)簡(jiǎn)單方法需要共享，也需要封裝為一個(gè)服務(wù)接口嗎??管理策略: 1、總體原則：仍然需要進(jìn)行統(tǒng)籌考慮，所有組件統(tǒng)一管理,組件放置在產(chǎn)品倉(cāng)庫(kù)中，每個(gè)產(chǎn)品或服務(wù)需要共享組件時(shí),從產(chǎn)品倉(cāng)庫(kù)獲取。?2、特殊情況：特殊服務(wù)需要使用特殊的組件、框架,需提出申請(qǐng)，統(tǒng)籌規(guī)劃后進(jìn)行決策。開(kāi)發(fā)階段服務(wù)的調(diào)用AIP網(wǎng)關(guān)調(diào)用所有服務(wù)通過(guò)Zｕｕl網(wǎng)關(guān)進(jìn)行調(diào)用,不允許直接調(diào)用微服務(wù)提供者。Ｚuul可能會(huì)成為系統(tǒng)瓶頸，在項(xiàng)目復(fù)雜時(shí)可考慮為Zｕul進(jìn)行主備或負(fù)載均衡處理。同步調(diào)用?采用HTTＰREST方式進(jìn)行調(diào)用，針對(duì)業(yè)務(wù)需求可以進(jìn)行負(fù)載均衡，負(fù)載均衡的調(diào)用方式有兩種：?1、FeｉgnClieｎt 2、RestＴｅｍplaｔｅ?建議使用ＦｅｉgnClienｔ方式進(jìn)行服務(wù)調(diào)用。?不管是什么方式，他都是通過(guò)REＳT接口調(diào)用服務(wù)的http接口,參數(shù)和結(jié)果默認(rèn)都是通過(guò)Ｊackson序列化和反序列化。因?yàn)椋觩ｒingMVＣ的RestＣontrｏｌleｒ定義的接口，返回的數(shù)據(jù)都是通過(guò)Ｊackｓon序列化成JSON數(shù)據(jù)。異步調(diào)用?rａbbitMq、kａｆka、SprinｇCｌouｄStream均是可以選擇的方案.SprｉngClｏｕｄStreａm，基于Redis、Rabbit、Kafkａ實(shí)現(xiàn)的消息微服務(wù),簡(jiǎn)單聲明模型用以在SprinｇCloud應(yīng)用中收發(fā)消息。服務(wù)間調(diào)用的權(quán)限驗(yàn)證一般我們的API接口都需要某種授權(quán)才能訪問(wèn),登陸成功以后，然后通過(guò)ｔokｅn或者ｃoｏkie等方式才能調(diào)用接口。使用ＳpringCloudＮetｆix框架的話(huà),登錄的時(shí)候,把登錄請(qǐng)求轉(zhuǎn)發(fā)到相應(yīng)的用戶(hù)服務(wù)上,登陸成功后，會(huì)設(shè)置ｃookie或headertoｋeｎ等。然后客戶(hù)端接下來(lái)的請(qǐng)求就會(huì)帶著這些驗(yàn)證信息，從Zuｕl網(wǎng)關(guān)傳到相應(yīng)的服務(wù)上進(jìn)行驗(yàn)證。Zuｕl網(wǎng)關(guān)在把請(qǐng)求轉(zhuǎn)發(fā)到后臺(tái)的服務(wù)的時(shí)候，會(huì)默認(rèn)把一些heａder傳到服務(wù)端，如：Cｏｏkie、Seｔ－Ｃookiｅ、Authorizatｉｏn.這樣,客戶(hù)端請(qǐng)求的相關(guān)headerｓ就可以傳遞到服務(wù)端，服務(wù)端設(shè)置的coｏkie也可以傳到客戶(hù)端。但是，如果你想禁止某些heaｄer透?jìng)鞯椒?wù)端，可以在Zｕul網(wǎng)關(guān)的aｐpｌiｃation.yml配置里通過(guò)下面的方式禁用:zuul:?routes:?users：

ｐaｔh：／users／*＊

ｓensiｔｉveHｅａders：Coｏkｉe,Sｅt—Coｏkｉe，Authoｒｉｚaｔion

sｅrvicｅＩd:user剛才說(shuō)了我們的某個(gè)服務(wù)有時(shí)候需要調(diào)用另一個(gè)服務(wù),這時(shí)候，這個(gè)請(qǐng)求不是客戶(hù)端發(fā)起，他的請(qǐng)求的ｈｅaｄer里面也不會(huì)有任何驗(yàn)證信息。這時(shí)候,要么，通過(guò)防火墻等設(shè)置,保證服務(wù)間調(diào)用的接口，只能某幾個(gè)地址訪問(wèn)；要么，就通過(guò)某種方式設(shè)置heaｄeｒ。同時(shí),如果你想在某個(gè)服務(wù)里面獲得這個(gè)請(qǐng)求的真是IP，（因?yàn)檎?qǐng)求的通過(guò)網(wǎng)關(guān)轉(zhuǎn)發(fā)而來(lái)，你直接通過(guò)ｒｅqｕest獲得ｉｐ得到的是網(wǎng)關(guān)的IP），就可以從heaｄerX-Ｆorwarded—Hosｔ獲得.如果想禁用這個(gè)hｅader，也可以:zuuｌ.addProｘyHeadｅｒs=falｓe如果你使用RestTemplate的方式調(diào)用，可以在請(qǐng)求里面添加一個(gè)有header的Optiｏns。也可以通過(guò)如下的攔截器的方式設(shè)置,它對(duì)ＲeｓtTemplate方式和FeignCｌｉenｔ的方式都可以起作用:@Beaｎ?pｕblｉｃRequestIｎterceptorrequｅｓtＩnteｒceptor()｛?returnnｅwReqｕestIntｅrｃepｔor（）{?@Overｒiｄｅ?pｕblicｖoiｄａpply（ReｑueｓtTemplaｔeｔemplatｅ){?StringaｕtｈToｋen=ｇetToken(）；?temｐlａt(yī)e.ｈeadｅｒ（AUTH_ＴO(shè)KEＮ_ＨEＡDER,authToｋeｎ）；?｝

｝;

｝服務(wù)編排?主要的作用是減少項(xiàng)目中的相互依賴(lài)。比如現(xiàn)在有項(xiàng)目a調(diào)用項(xiàng)目b，項(xiàng)目b調(diào)用項(xiàng)目c．.．一直到h，是一個(gè)調(diào)用鏈,那么項(xiàng)目上線(xiàn)的時(shí)候需要先更新最底層的h再更新ｇ．。。更新c更新b最后是更新項(xiàng)目a。這只是這一個(gè)調(diào)用鏈，在復(fù)雜的業(yè)務(wù)中有非常多的調(diào)用，如果要記住每一個(gè)調(diào)用鏈對(duì)開(kāi)發(fā)運(yùn)維人員來(lái)說(shuō)就是災(zāi)難.有這樣一個(gè)好辦法可以盡量的減少項(xiàng)目的相互依賴(lài)，就是服務(wù)編排,一個(gè)核心的業(yè)務(wù)處理項(xiàng)目,負(fù)責(zé)和各個(gè)微服務(wù)打交道。比如之前是a調(diào)用ｂ，b掉用c，c調(diào)用ｄ，現(xiàn)在統(tǒng)一在一個(gè)核心項(xiàng)目W中來(lái)處理,W服務(wù)使用a的時(shí)候去調(diào)用b，使用ｂ的時(shí)候W去調(diào)用c。 其實(shí)可以理解為面向?qū)ο蟮脑O(shè)計(jì),減少方法之間的一層層嵌套調(diào)用，而采取一個(gè)方法進(jìn)行業(yè)務(wù)流程的串聯(lián)，如方法Ｗ實(shí)現(xiàn)一個(gè)完整的業(yè)務(wù)處理，則采取下面方式:?fｕnctｉｏnw(） ｛ ?1、調(diào)用方法a; ２、調(diào)用方法b;?3、調(diào)用方法c；?}服務(wù)的熔斷處理?在服務(wù)之間進(jìn)行調(diào)用時(shí)，由于各種原因會(huì)導(dǎo)致遠(yuǎn)程服務(wù)不可用或壓力過(guò)載等異常導(dǎo)致的故障蔓延，此時(shí)需要有一種機(jī)制進(jìn)行保護(hù)處理。SｐrinｇＣloud通過(guò)Ｎetflix的Hyｓtｒｉx組件實(shí)現(xiàn)熔斷和降級(jí)處理解決此問(wèn)題。斷路器(CriｃuitBrｅakｅr）是一種能夠在遠(yuǎn)程服務(wù)不可用時(shí)自動(dòng)熔斷（打開(kāi)開(kāi)關(guān)），并在遠(yuǎn)程服務(wù)恢復(fù)時(shí)自動(dòng)恢復(fù)(閉合開(kāi)關(guān)）的設(shè)施,ＳpringCloud通過(guò)Netflix的Ｈyｓｔrix組件提供斷路器、資源隔離與自我修復(fù)功能。SprinｇcｌoｕdＨystrｉx熔斷器

?統(tǒng)一日志管理?不同微服務(wù)部署在不同節(jié)點(diǎn)上，登錄每個(gè)節(jié)點(diǎn)查看日志是比較麻煩的，同時(shí)對(duì)于需要關(guān)聯(lián)多個(gè)微服務(wù)日志聯(lián)合查看分析的情況將更加麻煩.伴隨節(jié)點(diǎn)數(shù)量的增加，如果沒(méi)有合適的管理機(jī)制與工具,定位問(wèn)題、發(fā)現(xiàn)問(wèn)題的復(fù)雜性將越來(lái)越大，將成指數(shù)級(jí)增長(zhǎng)，因此需要進(jìn)行統(tǒng)一日志管理。 1、建立統(tǒng)一的日志管理規(guī)范； 2、開(kāi)發(fā)并使用統(tǒng)一的日志組件,為所有微服務(wù)提供統(tǒng)一的日志服務(wù)，由loｇ4j或Ｂlitｚ4j封裝；?3、在每個(gè)服務(wù)節(jié)點(diǎn)上部署日志采集Agｅnt組件，由此Aｇent進(jìn)行日志的采集與轉(zhuǎn)發(fā)；?4、建立統(tǒng)一的日志中心，所有日志寫(xiě)入日志中心.?說(shuō)明:上述日志的實(shí)現(xiàn)由公司的“日志管理平臺(tái)”進(jìn)行實(shí)現(xiàn),采用的是ELK集合框架.?統(tǒng)一監(jiān)控管理 使用Hｙstｒix組件進(jìn)行服務(wù)的監(jiān)控，使用Nagioｓ進(jìn)行服務(wù)器等資源的監(jiān)控。 １、Hystrix,監(jiān)控和斷路器。我們只需要在服務(wù)接口上添加Ｈystｒｉx標(biāo)簽,就可以實(shí)現(xiàn)對(duì)這個(gè)接口的監(jiān)控和斷路器功能.

２、ＨysｔrixDashboaｒd，監(jiān)控面板，他提供了一個(gè)界面，可以監(jiān)控各個(gè)服務(wù)上的服務(wù)調(diào)用所消耗的時(shí)間等。

3、Turbｉne，監(jiān)控聚合，使用Ｈyｓtrｉx監(jiān)控,我們需要打開(kāi)每一個(gè)服務(wù)實(shí)例的監(jiān)控信息來(lái)查看。而Ｔu(píng)ｒbine可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個(gè)地方統(tǒng)一查看。這樣就不需要挨個(gè)打開(kāi)一個(gè)個(gè)的頁(yè)面一個(gè)個(gè)查看。統(tǒng)一配置管理?實(shí)現(xiàn)各微服務(wù)的統(tǒng)一參數(shù)配置以及版本管理，可采用公司的配置管理平臺(tái)或者ＳｐringＣloｕdＣonｆig配置中心。SprｉｎgＣloudConｆig配置中心

? SprｉngCloudConfig就是我們通常意義上的配置中心.SｐringClｏuｄConfig—把應(yīng)用原本放在本地文件的配置抽取出來(lái)放在中心服務(wù)器,本質(zhì)是配置信息從本地遷移到云端。從而能夠提供更好的管理、發(fā)布能力。

ＳprinｇCｌoudCｏnfig分服務(wù)端和客戶(hù)端，服務(wù)端負(fù)責(zé)將giｔ(svn）中存儲(chǔ)的配置文件發(fā)布成ＲEＳＴ接口,客戶(hù)端可以從服務(wù)端ＲESＴ接口獲取配置。但客戶(hù)端并不能主動(dòng)感知到配置的變化,從而主動(dòng)去獲取新的配置,這需要每個(gè)客戶(hù)端通過(guò)PＯST方法觸發(fā)各自的／refresh。 為解決配置信息能及時(shí)通知到各服務(wù),同時(shí)減少每個(gè)微服務(wù)處理配置信息更新的復(fù)雜度，為此我們通過(guò)消息總線(xiàn)來(lái)解決此問(wèn)題,方案如下:Ｇｉt倉(cāng)庫(kù)、CoｎfｉgServｅr、以及微服務(wù)“ＳerviceA"、“SerｖiｃeＢ"的實(shí)例中都引入了SpriｎｇCｌoｕdBus，所以他們都連接到了RａbbitMQ的消息總線(xiàn)上。從Giｔ倉(cāng)庫(kù)中配置的修改到發(fā)起/bus/reｆrｅｓh的POST請(qǐng)求這一步可以通過(guò)Giｔ倉(cāng)庫(kù)的WebＨook來(lái)自動(dòng)觸發(fā)。／bｕs/refresh請(qǐng)求不再發(fā)送到具體服務(wù)實(shí)例上，而是發(fā)送給CoｎfｉgSeｒver，并通過(guò)desｔinatｉon參數(shù)來(lái)指定需要更新配置的服務(wù)或?qū)嵗?。由于所有連接到消息總線(xiàn)上的應(yīng)用都會(huì)接受到更新請(qǐng)求,所以在WeｂＨｏoｋ中就不需要維護(hù)所有節(jié)點(diǎn)內(nèi)容來(lái)進(jìn)行更新，從而解決了通過(guò)WｅbＨｏｏｋ來(lái)逐個(gè)進(jìn)行刷新的問(wèn)題。分布式sessｉon?采用Redｉｓ作為緩存組件以及sｅssion的共享組件。 RＥSＴ資源響應(yīng)結(jié)構(gòu) 制定規(guī)范和解析方法.APＩ調(diào)用鏈追蹤?微服務(wù)架構(gòu)上通過(guò)業(yè)務(wù)來(lái)劃分服務(wù)的，通過(guò)ＲEＳT調(diào)用，對(duì)外暴露的一個(gè)接口，可能需要很多個(gè)服務(wù)協(xié)同才能完成這個(gè)接口功能，如果鏈路上任何一個(gè)服務(wù)出現(xiàn)問(wèn)題或者網(wǎng)絡(luò)超時(shí),都會(huì)形成導(dǎo)致接口調(diào)用失敗。隨著業(yè)務(wù)的不斷擴(kuò)張,服務(wù)之間互相調(diào)用會(huì)越來(lái)越復(fù)雜。SprｉｎgClｏｕdＳleuｔh主要功能就是在分布式系統(tǒng)中提供追蹤解決方案，并且兼容支持了zipｋiｎ,你只需要在pｏm文件中引入相應(yīng)的依賴(lài)即可。單元測(cè)試 做微服務(wù)架構(gòu)，進(jìn)行系統(tǒng)測(cè)試的復(fù)雜度較大,為保證產(chǎn)品質(zhì)量與開(kāi)發(fā)、測(cè)試效率,單元測(cè)試是必不可少的.?可采用Moｃk方式進(jìn)行測(cè)試模擬，由持續(xù)集成進(jìn)行自動(dòng)化單元測(cè)試的執(zhí)行以及結(jié)果輸出。代碼調(diào)試 對(duì)于單體架構(gòu)系統(tǒng)，可直接本地化調(diào)試，但對(duì)于微服務(wù)架構(gòu)，接口間的調(diào)用需采用遠(yuǎn)程通訊的方式，也就是說(shuō)被調(diào)用的服務(wù)必須啟動(dòng)后方可被調(diào)用，因此當(dāng)微服務(wù)增多時(shí)，你可能需要啟動(dòng)大量的微服務(wù)或者wｅb服務(wù)器，這給本地化調(diào)用與調(diào)試帶來(lái)了困難。?解決方案待研究.測(cè)試自動(dòng)化測(cè)試單元測(cè)試：??由開(kāi)發(fā)人員實(shí)現(xiàn)。? 采用Mocｋ方式進(jìn)行測(cè)試模擬,由持續(xù)集成進(jìn)行自動(dòng)化單元測(cè)試的執(zhí)行以及結(jié)果輸出.業(yè)務(wù)測(cè)試：? 開(kāi)發(fā)進(jìn)行實(shí)現(xiàn),測(cè)試也需考慮如何實(shí)現(xiàn)。 ?將多個(gè)服務(wù)或業(yè)務(wù)單元進(jìn)行串聯(lián),測(cè)試一個(gè)完整的業(yè)務(wù),甚至是不同業(yè)務(wù)之間組成的系統(tǒng)測(cè)試，需要采用相關(guān)的自動(dòng)化測(cè)試框架執(zhí)行，如ＲｏbotＦrameworｋ自動(dòng)化測(cè)試框架。依賴(lài)測(cè)試?也可以稱(chēng)為接口測(cè)試或者契約測(cè)試,在微服務(wù)逐漸增多的情況下，如何有效保證服務(wù)之間能夠按照接口的約定正常工作,即符合契約,成為微服務(wù)實(shí)施過(guò)程中,測(cè)試面臨的主要挑戰(zhàn)。 一、開(kāi)發(fā)自動(dòng)化的接口測(cè)試工具，?1、檢測(cè)接口是否滿(mǎn)足約定 2、檢測(cè)接口是否發(fā)生變化?３、檢測(cè)接口是否可以正常被調(diào)用。 二、測(cè)試方法: 采取基于消費(fèi)者驅(qū)動(dòng)的契約測(cè)試，測(cè)試架構(gòu)如下： 其優(yōu)勢(shì)如下：從價(jià)值實(shí)現(xiàn)的角度定義契約從消費(fèi)者使用契約的角度出發(fā),首先保證消費(fèi)者基于此契約是可以實(shí)現(xiàn)價(jià)值的,有了這個(gè)前提，再使用契約來(lái)驗(yàn)證提供者，如果提供者提供的契約同定義的契約一致，則證明提供者提供的契約是能夠?qū)崿F(xiàn)服務(wù)消費(fèi)者的。通過(guò)這種方式,使得更聚焦于如何從價(jià)值實(shí)現(xiàn)出發(fā).隔離消費(fèi)者和提供者的測(cè)試對(duì)于契約的消費(fèi)者和提供者可以分開(kāi)獨(dú)立測(cè)試,有效解決傳統(tǒng)集成測(cè)試服務(wù)架構(gòu)的弊端,將微服務(wù)的接口測(cè)試成本降到最低。 三、測(cè)試工具：?Ｐaｃｔ、Ｊaｎus、Ｐacｔo等。系統(tǒng)測(cè)試熔斷測(cè)試 1、通過(guò)停止微服務(wù)的方式測(cè)試服務(wù)路由的正確性?2、通過(guò)壓力測(cè)試，將某個(gè)微服務(wù)產(chǎn)生過(guò)載等異常，測(cè)試服務(wù)熔斷或降級(jí)?3、通過(guò)壓力測(cè)試，測(cè)試負(fù)載均衡策略的正確性性能測(cè)試?原有本地化的aｐｉ調(diào)用將會(huì)變成REST的遠(yuǎn)程調(diào)用,調(diào)用速度勢(shì)必受到影響，因此需要對(duì)系統(tǒng)性能進(jìn)行考慮以及性能測(cè)試，主要影響因素如下:1、網(wǎng)絡(luò):遠(yuǎn)程調(diào)用時(shí)受到網(wǎng)絡(luò)通訊速度的影響，這涉及到網(wǎng)絡(luò)速度、網(wǎng)絡(luò)部署以及系統(tǒng)架構(gòu),有相互依賴(lài)的服務(wù)應(yīng)采取就近部署原則。2、服務(wù)器:受到遠(yuǎn)程服務(wù)所在服務(wù)器性能的影響。3、數(shù)據(jù)量：數(shù)據(jù)量這里指的是數(shù)據(jù)大小以及數(shù)據(jù)傳輸?shù)拇螖?shù)以及頻率，此時(shí)REＳT調(diào)用方式會(huì)產(chǎn)生瓶頸，當(dāng)然，最好的方式是避免此種情況發(fā)生,此種場(chǎng)景采取消息中間件的方式異步通訊。持續(xù)集成?１、持續(xù)集成:每個(gè)微服務(wù)獨(dú)立執(zhí)行持續(xù)集成。 2、版本集成:由統(tǒng)一的集成工具,實(shí)現(xiàn)自動(dòng)化的版本集成，將所有微服務(wù)集成到統(tǒng)一的版本發(fā)布包中。?３、持續(xù)集成可制作多種場(chǎng)景的版本，包括測(cè)試環(huán)境、開(kāi)發(fā)環(huán)境、生產(chǎn)環(huán)境。 4、統(tǒng)計(jì)測(cè)試覆蓋率等指標(biāo)數(shù)據(jù). 5、工具:Jenkｉns、Sｏnar等。持續(xù)部署?1、通過(guò)持續(xù)集成自動(dòng)制作發(fā)布版本的Dockｅｒ鏡像;?2、將doｃker鏡像自動(dòng)上傳到dockeｒ容器中。?運(yùn)維階段遠(yuǎn)程升級(jí)?微服務(wù)不斷增加后，意味著部署容器也在同步增加,對(duì)于后續(xù)升級(jí)維護(hù)的工作量將會(huì)逐漸增加,開(kāi)發(fā)統(tǒng)一管理中心,支持遠(yuǎn)程維護(hù)與升級(jí)將可減少運(yùn)維的復(fù)雜度.統(tǒng)一配置中心?使用SpringＣloudConfig或者配置管理平臺(tái)進(jìn)行統(tǒng)一的配置管理。統(tǒng)一日志中心?使用日志管理平臺(tái)進(jìn)行統(tǒng)一的日志采集、日志分析?；冢蹋颮ａ的組網(wǎng)設(shè)計(jì)方案目錄1概述 １２功能性能指標(biāo) １2.1功能指標(biāo) 12.2性能指標(biāo) 23技術(shù)路線(xiàn)選擇 ３4系統(tǒng)設(shè)計(jì)?44.1系統(tǒng)組成?44。2系統(tǒng)工作模式 54.2。1主機(jī)輪詢(xún)的組網(wǎng)方式 ６4．2。2分時(shí)間片的組網(wǎng)方式?６５通信設(shè)計(jì) 75.1ＭODBＵS通信協(xié)議?7５.2MODBＵS通信示意圖 8６軟件設(shè)計(jì)?86.１軟件流程圖?8６．2軟件時(shí)序圖 97結(jié)構(gòu)設(shè)計(jì) 107。1接口設(shè)計(jì)?10７.2外形設(shè)計(jì) 1１８實(shí)驗(yàn)方案?129項(xiàng)目進(jìn)度和質(zhì)量保證?１39。１項(xiàng)目研制進(jìn)度計(jì)劃?139.２質(zhì)量控制與文件交付進(jìn)度計(jì)劃?1４１0主機(jī)與監(jiān)測(cè)系統(tǒng)通信協(xié)議 1４10．1概述 1４１０．2協(xié)議標(biāo)準(zhǔn)設(shè)置?1410.3字節(jié)格式?１５1０.4幀格式 1510．5浮點(diǎn)數(shù)存貯和傳輸格式 1610．6功能碼?1610.７讀寫(xiě)保持寄存器 1610.8舉例?17１0。9異常響應(yīng)?１910.10CRC16校驗(yàn)方式 １９1概述基于LoＲa的組網(wǎng)通信系統(tǒng)采用LoRａ通信協(xié)議進(jìn)行組網(wǎng)通信,系統(tǒng)由計(jì)算機(jī)終端、通信基站、集成通信模塊的用戶(hù)設(shè)備、具備通信功能的用戶(hù)設(shè)備等組成，實(shí)現(xiàn)整套系統(tǒng)的互相通信.2功能性能指標(biāo)2.１功能指標(biāo)ＬoRa組網(wǎng)通信功能：通過(guò)通信基站向全部設(shè)備廣播信息;通過(guò)通信基站向某一特定設(shè)備發(fā)送參數(shù)或控制命令;通信基站同時(shí)接收１6個(gè)設(shè)備的上傳數(shù)據(jù)。LｏRａ通信加密功能：無(wú)線(xiàn)通信具備加密功能，提供加密算法.設(shè)備命名功能:為每一個(gè)接入網(wǎng)絡(luò)的設(shè)備定義設(shè)備編號(hào)，名字可長(zhǎng)期不變,也可經(jīng)授權(quán)改變,可唯一識(shí)別不同的設(shè)備，滿(mǎn)足后續(xù)數(shù)據(jù)處理。485通信功能：按照485標(biāo)準(zhǔn)以及MODＢUS數(shù)據(jù)格式，通信模塊可完成與用戶(hù)模塊電路之間的數(shù)據(jù)通信.調(diào)試界面軟件功能:實(shí)時(shí)顯示各設(shè)備數(shù)據(jù),包括設(shè)備工作狀態(tài)、設(shè)備傳感器數(shù)據(jù);設(shè)置設(shè)備參數(shù)與狀態(tài)，包括設(shè)備命名與修改、下達(dá)復(fù)位命令、設(shè)置報(bào)警值、設(shè)置數(shù)據(jù)上傳時(shí)間間隔、啟停數(shù)據(jù)采集等;存儲(chǔ)數(shù)據(jù)，按照不同任務(wù)、不同設(shè)備進(jìn)行關(guān)聯(lián)存儲(chǔ);數(shù)據(jù)可查詢(xún);數(shù)據(jù)可打印。AＰI接口通信功能：按照MＯDＢＵＳ數(shù)據(jù)格式和LｏRa通信協(xié)議，建立界面軟件(包括調(diào)試界面軟件)和通信基站之間通信通道，界面軟件可實(shí)現(xiàn)相應(yīng)功能。故障顯示與定位功能:當(dāng)通信基站和通信模塊發(fā)生故障時(shí)，界面可顯示故障，并顯示具體哪一個(gè)通信模塊或通信基站發(fā)生故障。２。2性能指標(biāo)無(wú)線(xiàn)通信體制:LoRa通信，一個(gè)基站對(duì)多個(gè)通信設(shè)備的組網(wǎng)通信。無(wú)線(xiàn)通信距離：無(wú)遮擋傳輸距離≥5０00ｍ,有金屬遮擋傳輸距離≥20０0ｍ.無(wú)線(xiàn)通信速率:通信基站向用戶(hù)設(shè)備下傳數(shù)據(jù)≥1kbpｓ；用戶(hù)設(shè)備向通信基站上傳數(shù)據(jù)≥５kbpｓ；通信基站數(shù)據(jù)吞吐速率≥１０kbps,可同時(shí)接收≥16路的設(shè)備上傳數(shù)據(jù);有遮擋時(shí),上傳和下傳數(shù)據(jù)率的衰減量≤50%。通信模塊供電:采用+12V電源供電。通信基站功耗:通過(guò)DC12V電源適配器進(jìn)行設(shè)備供電。數(shù)據(jù)加密：無(wú)線(xiàn)通信上傳和下傳數(shù)據(jù)進(jìn)行加密,16路同時(shí)上傳時(shí),數(shù)據(jù)吞吐速率不超過(guò)通信基站額定能力的70％。提供數(shù)據(jù)加解密算法.485通信速率:通信模塊向用戶(hù)模塊電路的下傳數(shù)據(jù)速率≥１kｂｐｓ;用戶(hù)模塊電路向通信模塊的上傳數(shù)據(jù)速率≥5ｋｂｐs；數(shù)據(jù)格式采用ＭODＢＵＳ通訊協(xié)議。一次工作時(shí)間：一次開(kāi)機(jī),可可靠連續(xù)工作12h.工作溫度：－3５℃~55℃。存儲(chǔ)溫度:-40℃～70℃.濕度:４0℃工作溫度下，9０％濕度，通信基站、通信模塊能正常工作，且不凝露。元器件和原材料的性能參數(shù)滿(mǎn)足環(huán)境溫度（工作溫度、存儲(chǔ)溫度）要求。3技術(shù)路線(xiàn)選擇LoRａ是LPWAN(低功耗廣域物聯(lián)網(wǎng)）通信技術(shù)中的一種，LoＲa作為目前最有發(fā)展前景的低功耗廣域通信技術(shù),已經(jīng)被運(yùn)用在個(gè)各行各業(yè)中。是美國(guó)Semｔech公司采用和推廣的一種基于擴(kuò)頻技術(shù)的超遠(yuǎn)距離無(wú)線(xiàn)傳輸方案。LoRa無(wú)線(xiàn)通信采用直序擴(kuò)頻技術(shù)，具有通信距離遠(yuǎn)、功率密度集中，抗干擾能力強(qiáng)的優(yōu)勢(shì).同時(shí)具有軟件FEＣ前向糾錯(cuò)算法,其編碼效率較高,糾錯(cuò)能力強(qiáng)，在突發(fā)干擾的情況下，能主動(dòng)糾正被干擾的數(shù)據(jù)包,大大提高可靠性和傳輸距離.目前,LoRa主要在全球免費(fèi)頻段運(yùn)行，包括433、8６8、915ＭHz等.ＬoRａ是物聯(lián)網(wǎng)應(yīng)用中的無(wú)線(xiàn)技術(shù)有多種,可組成局域網(wǎng)或廣域網(wǎng)。ZigＢee是一種無(wú)線(xiàn)連接,可工作在2．4GHz（全球流行）、868MHｚ(歐洲流行)和91５MHz（美國(guó)流行）３個(gè)頻段上，是一種近距離、低復(fù)雜度、低功耗、低速率、低成本的雙向無(wú)線(xiàn)通訊技術(shù)?；诖?，我們選擇傳輸距離遠(yuǎn)、功耗低(長(zhǎng)電池壽命）的LoRa模塊。４系統(tǒng)設(shè)計(jì)基于LoＲa的組網(wǎng)通信系統(tǒng)由計(jì)算機(jī)終端、通信基站、集成通信模塊的用戶(hù)設(shè)備、具備通信功能的用戶(hù)設(shè)備等組成，系統(tǒng)采用LoＲa通信協(xié)議進(jìn)行組網(wǎng)通信，實(shí)現(xiàn)命令或參數(shù)的下達(dá)，以及數(shù)據(jù)的采集與上傳等功能.圖4．1基于ＬoRａ的組網(wǎng)通信系統(tǒng)組成示意圖4。1系統(tǒng)組成系統(tǒng)由計(jì)算機(jī)終端、通信基站、集成通信模塊的用戶(hù)設(shè)備（設(shè)備1~設(shè)備10)、具備通信功能的用戶(hù)設(shè)備(設(shè)備11～設(shè)備1６）等組成.表SＥQ表\＊ＡRABIC１設(shè)備清單序號(hào)名稱(chēng)數(shù)量說(shuō)明1通信基站1臺(tái)提供技術(shù)手冊(cè)。2通信模塊10塊提供技術(shù)手冊(cè).3基站天線(xiàn)1套SMA接口；提供技術(shù)手冊(cè)。４設(shè)備天線(xiàn)10套防水、防塵；ＳMA接口；提供技術(shù)手冊(cè)。５通信模塊電纜１0套每套含:一根300mm的SMA電纜；一根300mm的485通信電纜（含接插件，提供定義，3個(gè)信號(hào)線(xiàn)）；一根30０mm的供電電纜（SMA接口）;一根48５轉(zhuǎn)UＳB電纜。6AＰＩ接口軟件1套提供使用說(shuō)明書(shū)。7LoRa通信協(xié)議與MODBUS數(shù)據(jù)格式１套采用該通信協(xié)議和數(shù)據(jù)格式，可滿(mǎn)足其他設(shè)備實(shí)現(xiàn)LoRａ通信功能設(shè)計(jì).8調(diào)試界面軟件1套供系統(tǒng)集成調(diào)試用,提供說(shuō)明書(shū)。4。２系統(tǒng)工作模式因射頻的特性決定了無(wú)線(xiàn)串口收發(fā)模塊可以一發(fā)多收,不能同時(shí)多發(fā)一收,造成了射頻組網(wǎng)的最大的障礙，因此,為了解決這個(gè)問(wèn)題就只能夠利用時(shí)間來(lái)實(shí)現(xiàn)組網(wǎng)，下面是無(wú)線(xiàn)LoRa收發(fā)模塊實(shí)現(xiàn)多發(fā)一收的解決方案。4．２.1主機(jī)輪詢(xún)的組網(wǎng)方式主機(jī)輪詢(xún)方式組網(wǎng)是主機(jī)逐個(gè)查詢(xún)的方式，該組網(wǎng)方式能夠準(zhǔn)確上傳,并且相互設(shè)備之間不容易出現(xiàn)沖突，組網(wǎng)也比較穩(wěn)定,但是缺點(diǎn)是主機(jī)輪詢(xún)耗時(shí)間長(zhǎng)。這種組網(wǎng)方式適合那些對(duì)時(shí)間要求不高的組網(wǎng)應(yīng)用。主機(jī)輪詢(xún)的組網(wǎng)方式原理很簡(jiǎn)單,通過(guò)點(diǎn)名的方式實(shí)現(xiàn)應(yīng)答.如主機(jī)發(fā)送給1號(hào)從機(jī)，由于從機(jī)都有地址設(shè)別，因此只有從機(jī)1能夠響應(yīng)主機(jī)。從機(jī)1收到主機(jī)的命令后,將數(shù)據(jù)上傳給主機(jī)。主機(jī)再以相同點(diǎn)的輪詢(xún)方式輪詢(xún)其它從機(jī)數(shù)據(jù).圖4。２主機(jī)輪詢(xún)組網(wǎng)圖4。2．2分時(shí)間片的組網(wǎng)方式分時(shí)間片的組網(wǎng)方式對(duì)于組網(wǎng)數(shù)據(jù)收集來(lái)說(shuō)是比簡(jiǎn)單的輪詢(xún)方式快了很多，但是對(duì)從機(jī)的時(shí)間同步以及發(fā)送延遲要求高。圖4.3分時(shí)間片組網(wǎng)圖如圖,這種組網(wǎng)方式是先由主機(jī)發(fā)起廣播時(shí)間，從機(jī)收到后,同步自己的本地時(shí)間，同步完成后，根據(jù)自己的編號(hào)進(jìn)行延時(shí)上傳,從而實(shí)現(xiàn)多發(fā)一收的功能.這種組網(wǎng)方式收發(fā)數(shù)據(jù)時(shí)間節(jié)省很多，并且能夠防止沖突，但是對(duì)軟件延時(shí)等調(diào)整要求較高。為保證數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性，選擇第二種方式分時(shí)間片的組網(wǎng)方式，實(shí)現(xiàn)整個(gè)系統(tǒng)的無(wú)線(xiàn)通信。5通信設(shè)計(jì)５.１MＯＤBＵS通信協(xié)議ＭODBUS網(wǎng)絡(luò)是一個(gè)工業(yè)通信系統(tǒng),由帶智能終端的可編程序控制器和計(jì)算機(jī)通過(guò)公用線(xiàn)路或局部專(zhuān)用線(xiàn)路連接而成。其系統(tǒng)結(jié)構(gòu)既包括硬件、亦包括軟件。它可應(yīng)用于各種數(shù)據(jù)采集和過(guò)程監(jiān)控。它已經(jīng)成為一種通用工業(yè)標(biāo)準(zhǔn)。ＭODBUＳ網(wǎng)絡(luò)只有一個(gè)主機(jī)，所有通信都由它發(fā)出。網(wǎng)絡(luò)可支持247個(gè)之多的遠(yuǎn)程從屬控制器,但實(shí)際所支持的從機(jī)數(shù)要由所用通信設(shè)備決定。MＯＤBＵS協(xié)議定義了一個(gè)控制器能認(rèn)識(shí)使用的消息結(jié)構(gòu),而不管它們是經(jīng)過(guò)何種網(wǎng)絡(luò)進(jìn)行通信的。它描述了一個(gè)控制器請(qǐng)求訪問(wèn)其它設(shè)備的過(guò)程，如何回應(yīng)來(lái)自其它設(shè)備的請(qǐng)求,以及怎樣偵測(cè)錯(cuò)誤并記錄。它制定了消息域格局和內(nèi)容的公共格式。MODＢUS網(wǎng)絡(luò)以ＲTU模式進(jìn)行通信，在消息中的每個(gè)8Bit字節(jié)按照原值傳送，不做處理。這種方式的主要優(yōu)點(diǎn)是：數(shù)據(jù)幀傳送之間沒(méi)有間隔,相同波特率下傳輸數(shù)據(jù)的密度要比ＡSCＩI高，傳輸速度更快。5.２MODBUS通信示意圖本系統(tǒng)由無(wú)線(xiàn)LoRa和有線(xiàn)485進(jìn)行組網(wǎng)通信。均采用ＭＯDBUS通信協(xié)議RTＵ通信方式?？蛇M(jìn)行點(diǎn)對(duì)點(diǎn)通信和點(diǎn)（基站）對(duì)多(模塊）通信。圖5.1基于ＬoRa的通信示意圖軟件設(shè)計(jì)6。1軟件流程圖監(jiān)測(cè)主機(jī)界面軟件主要對(duì)整個(gè)系統(tǒng)的運(yùn)行狀況進(jìn)行監(jiān)控。出現(xiàn)異常情況時(shí)，給出報(bào)警提示;同時(shí)可進(jìn)入設(shè)置界面進(jìn)行參數(shù)設(shè)置，對(duì)歷史數(shù)據(jù)存儲(chǔ)和打印.圖6。1監(jiān)測(cè)主機(jī)軟件流程圖6.2軟件時(shí)序圖監(jiān)測(cè)主機(jī)界面軟件可通過(guò)無(wú)線(xiàn)LｏＲa或者有線(xiàn)４8５進(jìn)行通信。監(jiān)測(cè)主機(jī)作為主機(jī)，可對(duì)任一設(shè)備進(jìn)行點(diǎn)對(duì)點(diǎn)通信，也可通過(guò)廣播命令控制所有從機(jī)，當(dāng)主機(jī)獲取所有從機(jī)數(shù)據(jù)時(shí),從機(jī)根據(jù)設(shè)備編號(hào)延時(shí)間隔固定時(shí)間依次回應(yīng)數(shù)據(jù)。圖6．2監(jiān)測(cè)主機(jī)軟件時(shí)序圖7結(jié)構(gòu)設(shè)計(jì)通信基站和通信模塊采用如圖所示外形結(jié)構(gòu)和安裝尺寸，包括各接口定義。７．1接口設(shè)計(jì)圖７.１電氣接口示意圖圖7.2狀態(tài)指示圖表2電氣接口定義表腳號(hào)名稱(chēng)功能說(shuō)明1DB-９母型插座RS—２32接口標(biāo)準(zhǔn)RＳ－2３2接口2３．81接線(xiàn)端子RS—4８5、電源接口標(biāo)準(zhǔn)RS－232接口與壓線(xiàn)式電源接口3ＰＷR(shí)-ＬＥD電源指示燈紅色,電源接通時(shí)點(diǎn)亮4TXD—LＥD發(fā)送指示燈黃色，發(fā)送數(shù)據(jù)時(shí)閃爍5RXD—LED接收指示燈黃色，接收數(shù)據(jù)時(shí)閃爍6DC電源接口電源接口直插式圓孔5。5＊2.５mm7撥碼開(kāi)關(guān)撥碼開(kāi)關(guān)工作模式控制8天線(xiàn)接口ＳMＡ-K接口外螺紋內(nèi)孔,長(zhǎng)10mm,特征阻抗50Ω*注:DＣ電源接口和3。81接線(xiàn)端子供電均為12V，根據(jù)現(xiàn)場(chǎng)接線(xiàn)情況二選一即可。7．２外形設(shè)計(jì)圖7．３結(jié)構(gòu)外形尺寸圖8實(shí)驗(yàn)方案序號(hào)試驗(yàn)項(xiàng)目名稱(chēng)試驗(yàn)樣品數(shù)量試驗(yàn)結(jié)果試驗(yàn)單位1外觀、重量、尺寸全檢檢驗(yàn)報(bào)告陜西衛(wèi)峰2無(wú)線(xiàn)通信距離抽檢測(cè)試報(bào)告陜西衛(wèi)峰3無(wú)線(xiàn)通信速率抽檢測(cè)試報(bào)告陜西衛(wèi)峰4通信模塊供電與功耗抽檢測(cè)試報(bào)告陜西衛(wèi)峰５通信基站功耗抽檢測(cè)試報(bào)告陜西衛(wèi)峰6一次工作時(shí)間抽檢檢驗(yàn)報(bào)告陜西衛(wèi)峰772ｈ穩(wěn)定性試驗(yàn)全檢檢驗(yàn)報(bào)告陜西衛(wèi)峰８工作高溫試驗(yàn)抽檢檢驗(yàn)報(bào)告陜西衛(wèi)峰９工作低溫試驗(yàn)抽檢檢驗(yàn)報(bào)告陜西衛(wèi)峰１0工作濕度試驗(yàn)抽檢檢驗(yàn)報(bào)告陜西衛(wèi)峰11貯存高溫試驗(yàn)型式試驗(yàn)檢驗(yàn)報(bào)告陜西衛(wèi)峰12貯存低溫試驗(yàn)型式試驗(yàn)檢驗(yàn)報(bào)告陜西衛(wèi)峰9項(xiàng)目進(jìn)度和質(zhì)量保證9．1項(xiàng)目研制進(jìn)度計(jì)劃序號(hào)名稱(chēng)時(shí)間備注1簽訂合同合同簽訂之日起算T０2質(zhì)量計(jì)劃1周T0+１3研制方案1周T0+1４研制方案評(píng)審１周Ｔ0+2５工程樣機(jī)4周Ｔ０+66工程樣機(jī)試驗(yàn)2周Ｔ0+8７設(shè)備制造6周T0+148試驗(yàn)大綱３周T0＋1４9型式試驗(yàn)2周T０＋16１0出廠驗(yàn)收２周Ｔ0＋189.2質(zhì)量控制與文件交付進(jìn)度計(jì)劃文件清單如下:序號(hào)文件名稱(chēng)文件類(lèi)型提交進(jìn)度1技術(shù)文件、圖紙１.1研制方案I合同簽訂后２周內(nèi)1.2設(shè)備外形圖、安裝圖、外部接線(xiàn)圖I合同簽訂后2周內(nèi)１。３通訊協(xié)議說(shuō)明（LｏRa）Ｉ合同簽訂后2周內(nèi)１.4安裝說(shuō)明書(shū)I合同簽訂后10周內(nèi)2質(zhì)保文件2.1產(chǎn)品出廠合格證明書(shū)Ｉ設(shè)備交運(yùn)前１0主機(jī)與監(jiān)測(cè)系統(tǒng)通信協(xié)議10。1概述本協(xié)議規(guī)定了主機(jī)與監(jiān)測(cè)系統(tǒng)的通信協(xié)議，所有相關(guān)硬件設(shè)備都應(yīng)遵從協(xié)議規(guī)范。10。２協(xié)議標(biāo)準(zhǔn)設(shè)置采用RS—４85標(biāo)準(zhǔn)接口?！獦?biāo)準(zhǔn)協(xié)議：ModbusRTU協(xié)議?！?波特率：９600bps?！?設(shè)備地址：１－2４７（出廠默認(rèn)值為０0Ｈ)?！ㄓ嵎绞剑罕O(jiān)測(cè)主機(jī)主機(jī)主動(dòng)發(fā)送命令，便攜主機(jī)被動(dòng)應(yīng)答.１0．3字節(jié)格式編碼系統(tǒng)：８位二進(jìn)制，十六進(jìn)制0‐9,A‐F。數(shù)據(jù)位：1起始位，8位數(shù)據(jù)（低位先送）,無(wú)奇偶校驗(yàn),停止位1位.錯(cuò)誤校驗(yàn)區(qū):循環(huán)冗余校驗(yàn)（CRC16)

RTU錯(cuò)誤校驗(yàn)碼為2字節(jié)16位CRC碼.10.４幀格式Ｍｏdbus信息以幀的方式傳輸,每幀有確定的起始點(diǎn)和結(jié)束點(diǎn),使接收設(shè)備在信息的起點(diǎn)開(kāi)始讀地址，并確定要尋址的設(shè)備（廣播時(shí)對(duì)全部設(shè)備)，以及信息傳輸?shù)慕Y(jié)束時(shí)間。RTU模式中，信息開(kāi)始至少需要3。５個(gè)字節(jié)的靜止時(shí)間，發(fā)送完最后一個(gè)字節(jié)后,也有一個(gè)3。5個(gè)字符的靜止時(shí)間。整個(gè)信息必須連續(xù)發(fā)送。如果在發(fā)送幀信息期間,出現(xiàn)大于1．５個(gè)字符的靜止時(shí)間時(shí),則接收設(shè)備刷新不完整的信息,并假設(shè)下一個(gè)地址數(shù)據(jù)。開(kāi)始地址功能數(shù)據(jù)校驗(yàn)終止T１—Ｔ2－T3-T４8biｔs8bｉtsＮ*8biｔs1６bitsT1—T2—Ｔ3－T410.5浮點(diǎn)數(shù)存貯和傳輸格式浮點(diǎn)數(shù)采用IEEE標(biāo)準(zhǔn)的單精度浮點(diǎn)數(shù)格式，如圖所示，每個(gè)數(shù)由4字節(jié)組成，數(shù)據(jù)傳輸時(shí),從第一字節(jié)到第四字節(jié)的順序傳送。10.６功能碼功能代碼功能名稱(chēng)０３(０x０3)讀寄存器06（0x06)寫(xiě)單個(gè)寄存器1６（0x1０）寫(xiě)多個(gè)寄存器1０。7讀寫(xiě)保持寄存器地址高字節(jié)低字節(jié)數(shù)據(jù)類(lèi)型備注0０H實(shí)時(shí)數(shù)據(jù)ｆloat只讀01H02H報(bào)警狀態(tài)TF卡狀態(tài)ucｈaｒ只讀0３H電池電量uｃhａr只讀０4H年月uchar讀寫(xiě)05H日時(shí)ｕcｈar0６Ｈ分秒ucｈar0７H報(bào)警閾值ｆｌoａt(yī)讀寫(xiě)０8H０9H報(bào)警時(shí)間uｃhａｒ讀寫(xiě)0ＡH密鑰設(shè)備編號(hào)ucｈar只限4８5接口0BＨ系統(tǒng)復(fù)位ucｈar只寫(xiě)02H、報(bào)警狀態(tài):0=正常，1=報(bào)警。TＦ卡狀態(tài)：0＝正常，１=異常。03Ｈ、電量：0－10０.09H、報(bào)警時(shí)間：0=０．５s,1＝１s，2=2ｓ。0ＡH、設(shè)備編號(hào):1—247。0BＨ、系統(tǒng)復(fù)位:寫(xiě)入０x00AＡ可復(fù)位。10.8舉例1、讀取設(shè)備數(shù)據(jù)與狀態(tài):0１030００0００0７xxxｘ(地址0１）地址功能碼寄存器起始地址寄存器數(shù)量CRC01030０0０0007xxｘx從應(yīng)答：０103０7０00０００50120701090C22xxxx地址功能碼字節(jié)數(shù)實(shí)時(shí)數(shù)據(jù)（4字節(jié))報(bào)警、TF卡０1０30E3Ｄ４ＣCCCD0００0電池電量時(shí)間CRC005012０701090C22xxｘx實(shí)時(shí)數(shù)據(jù)0。05Bq／cm2,未報(bào)警,ＴＦ卡正常，80％，18年7月1日9時(shí)12分34秒。２、讀取報(bào)警時(shí)間:010300０900０1xxxx（地址01)地址功能碼寄存器起始地址寄存器數(shù)量CRＣ0１03０0０９０001xxxx從應(yīng)答：010３0２０00１ｘｘxx地址功能碼字節(jié)數(shù)數(shù)據(jù)ＣRC0103020001xxxx報(bào)警時(shí)間為1s。寫(xiě)系統(tǒng)時(shí)間：01１00０0４000３１20701090C22xxｘx地址功能碼起始地址寄存器數(shù)量數(shù)據(jù)CＲC0110000４０003120７０1090C22ｘｘｘx從應(yīng)答:０10３０２0001xxxx地址功能碼起始地址寄存器數(shù)量CＲC011000040003xxxx系統(tǒng)復(fù)位：０106000B00AＡxｘxx地址功能碼寄存器起始地址數(shù)據(jù)CＲＣ０１0６000B00AAxxxx從應(yīng)答:0１0６００0B０0AＡxxxx（成功原樣返回)地址功能碼寄存器起始地址數(shù)據(jù)CＲC０1０60０0B０0AAxxxx10。９異常響應(yīng)出現(xiàn)異常指令時(shí)，設(shè)置功能碼的MSＢ為1。這使得異常響應(yīng)中的功能碼值比正常響應(yīng)中的功能碼值高0x80，返回異常指令.地址功能碼異常碼CRC０18０｜xxｘxｘxxｘ異常碼內(nèi)容0１非法功能碼02非法數(shù)據(jù)地址03非法數(shù)據(jù)10.10CRC16校驗(yàn)方式staticcｏnｓtuｉnt8auchCRCHi［］=｛0x0０,0ｘC1，0x81，0x４0,０x01，０xC0,０x80，0x41，０x01,0xC0,0x8０,0ｘ41,0x00，０xC1，０x8１，0ｘ40，0x01，0xＣ０，0ｘ8０，0x4１,0x00,０xC1,0x81,0x4０，0x00,０xＣ１，0x81，0x4０,0ｘ01,0xC0,０x80，0x41,0x01，０xC0,０x8０，0ｘ41，0x00，0ｘＣ１,０x８1,0x４０,0x00,0ｘC1，0x81，0ｘ40，0x0１，0ｘC0，0x８0，0x41,0x00,0xC1，0ｘ8１，0x4０，0x01,0xC0，０x80，0x41，０x01，０xC0,0ｘ80,０x41，０x00,0xＣ1,0x81，0x40，０x01,０xC0，0ｘ8０，0x４1,０x0０,0xＣ1，０x81，0x40,０x00，０xC1，0x81，0x4０,0ｘ01，0ｘC0,0x８0,0x4１，０x00，０ｘC1，0x８1,０x40，０x01,0xC0，０x80，0ｘ41，0ｘ０１，０xＣ0，0x80，0x４1，0x00，0ｘC１，０x8１,0x40，0ｘ00,０xC1，０x81，0x40,0x01，0xＣ0，0x８0，0x41，0ｘ０1，0xC0，０x８0，0x4１，0x0０,0xC1，0x81，0x40，0x0１，0xC０,０x８０，0x4１,0x00,０xC1，0x81,0x40，０ｘ００,０xC1,0x81,０x４0，0x01，0ｘC0，0x８０,０x41，0ｘ0１，0xC0，0x80，０x41，0x0０，０xC1,０ｘ81，0x4０,0x00，０xC１，０ｘ８1,０x4０，0ｘ01，0xC０，0x８0,０x41，０ｘ00，0xＣ1,0ｘ81，０x40，0x01，0xC0，０x80，0x４1，0ｘ01,0xC0,0ｘ8０,0ｘ41,0x00，0xＣ1，０x８1,0x40,0x00，0ｘC1,0ｘ81，0x４0，0x０1，0ｘC０,0x80，0x4１,0x01,０xＣ０，0x8０,0x41,0ｘ０0,0xC１,0ｘ81,0ｘ4０，0x01，0xC0，0x80，０ｘ41，0ｘ０0,０xC1,０x81,0x４０,0x00,0xＣ1，0ｘ８1，0x4０，0ｘ01，0xC0，0x８0，0x41,０ｘ0０，０xC１，０x81，0ｘ40，0x０1,0xC0,0ｘ80，0x４１，0x01,0xＣ0,０ｘ80，0x４1，０ｘ00,0xC1,０x81，0x4０，０x01，０xC0，0x80，０ｘ41，0x00,０xＣ1，0x８1,０ｘ40，0x０0,０ｘC1,0x81，0ｘ40,０ｘ01,0ｘC０,0x80，0x41,０x01，0xC０，0x80,0x4１,0x0０,0ｘＣ1,0x8１,０ｘ４0,0x00,0xC1，０ｘ81,0x４0，0x01,0xC0，0x80,0x４1，0x0０,０xC1，0x81,0ｘ40,0x0１，0xC０，0x８０,０ｘ41,0x01,0ｘC0,０x80,0ｘ41，0x００,０xC１,０ｘ81，０x４0}；stａt(yī)iｃｃｏnｓtuint8auchCRCLo［]=｛0x００，0xC0,0xC１，０ｘ01，0xC3,0ｘ03,0x０２,0ｘC2，０xC6，０ｘ06，0x０7,0xC7，０x0５，0xＣ5,０ｘC４，０x０4，０ｘCC,0x0C，0x0D,0xCD,0x0F,0ｘCF，0ｘCE，0x０Ｅ,0x0A,0xCA，0xCＢ，０x0B，0xC9,0ｘ09，0ｘ08，0ｘC8，0ｘD8,０x18，0x19,０ｘD９,0x1B,0ｘDB,0xDA，0ｘ1A，0x1Ｅ，0ｘDE,０xDF，0x1F,０xDD，0x1D，0ｘ１Ｃ，0xＤC,０x１4,0xＤ4，0xD5,0x15,0xＤ7,0x17，０x１6，0ｘD６,0ｘD2，0x1２，0x13，０xD３,0x11,0xD1，0ｘD0，0x10,0ｘF0,0x30,0x31,０ｘＦ1，0x3３，0ｘF3，0xF2,0x32，0x36,０xF6，0xF7，０ｘ37,０xＦ5,０x35,0x3４，０ｘF4，0ｘ3C，０xＦC，０xFD，0ｘ３D，０ｘFF，０x３F，0x３E,0xFE，0xFA,0x3A,０x３B,０ｘFB,0x３9，0xF9，０ｘF8，0ｘ３8，0x28，０xE８,０xE9,０x2９，0xEB,0ｘ2B,0x2Ａ，0xEＡ,0xEE,0x2E,0x2F，0xEＦ，0ｘ2Ｄ,0ｘED，０xEC,0x2C,０xE4,0x24，0x25，0xＥ5，0x２7，０ｘE７,0ｘE6，0x26，0x２2,０ｘE2，0xE3,0x23，０xE1，0x21，0x2０,0ｘE０，０ｘA0，0x６0,０x６1，０xＡ1，0x63，０xA3，0xA2，0x62，0x６6，０xA6,０xＡ７，0x6７，0ｘA5，0x65,0x6４，0xＡ4，0x６Ｃ,0xAC,0xAD，0x６D，0ｘAF，０x６Ｆ，0x6E，0xAE，０xＡA,０x6Ａ,0ｘ6Ｂ,0ｘAB,０x69，0xA9，0ｘA8，0x６8，０x78,０xB8，0xB9，0x７９,0xBＢ,0ｘ７B，0x7A，0xBA，0xBE，0x7E,０x7F,0xBF，0ｘ7D,０xBD，0xＢC，0x7C,0xＢ4，0x７4,0x7５，0xB5，0x77，0xB7,0ｘB(niǎo)６,０x76，0ｘ7２,0xB2,０xB3，0ｘ７3，0xB1，0ｘ71,０x70,０xＢ0,0ｘ50,0ｘ9０，0ｘ91,０x５1,0x93，0x5３,0x52,０x９2,0x96，0x56,0x5７，0x9７,0x５5，０x95,0x94，０x54,0ｘ9C,０x5C,0x5D，0ｘ9D，０x5F，0x9F，0x9E,0x5Ｅ，0ｘ５A(chǔ)，0x9A，0x9Ｂ,０x5B,0x99,０ｘ59,0x５8,０x98，0x８8，0x4８，０x49,0ｘ8９，0x4B,0x8B，０x8A,0ｘ4A，0x４E，0x8E，０x8F,0ｘ4F,０x8D,0x4Ｄ,0ｘ4C，０x８C,0x44,0x８4，0x85，0x４5,0x87,0x4７,0ｘ4６,0x86,0x82,0x4２，0x43，0x83，0x4１，０ｘ８1，0ｘ80,０x40｝；/＊＊＊＊＊＊**＊***＊*＊＊＊***＊＊＊＊*＊＊＊＊**＊＊＊＊**＊＊*＊＊*＊＊＊**＊＊＊*＊＊＊＊＊＊**＊*＊*Functｉon?：ｃalculate_ｃrc*Dｅsｃriptｉｏn ：計(jì)算校驗(yàn)和*ＩｎputParａ?：＊OutputPａｒa?：*ReturｎVaｌue：＊＊**＊＊＊＊＊**＊**＊**＊*＊＊＊＊*＊＊*****＊＊＊＊*＊＊*＊*＊＊＊*＊＊＊*＊＊*＊＊*＊＊**＊**＊/uｉnｔ16ｃalcｕlatｅ＿ｃrc（uiｎt8*ｐuchMsg,uint8ｕsDataLen){uiｎｔ8ucｈCRCHｉ=０xFF；uｉnt8ucｈCRCＬo=０xFＦ;uint8uIｎｄｅx；?ｕint１6CｒＣ16;whｉle（usDataＬｅn-—）｛ｕIｎdeｘ＝uchCＲCＨi^（*（pucｈMsg++）)；uchＣRCHi=ｕchCRCLo^ａuchＣRCHi[uIｎdex］；uchＣRCLo=ａuchＣRCLo[uIndeｘ］；} CrC１6=uｃhCＲＣＬo; CrＣ１6＜<＝8; ＣrC16+＝uchCRCHi；retｕrnＣrC16；｝目錄摘要···········································································································································11設(shè)計(jì)目的·······························································································································12設(shè)計(jì)要求·······························································································································１3設(shè)計(jì)內(nèi)容·······························································································································2３。１S3Ｃ2410與串口通信概述·····························································································23.1.1S2C241０處理器概述·······························································································23．1.2串口通信················································································································33．2方案設(shè)計(jì)························································································································43.3電路設(shè)計(jì)························································································································4３。3。1電源設(shè)計(jì)···········································································································43.3。2晶振電路·············································································································５3.３．3復(fù)位電路·············································································································６3.3。5存儲(chǔ)器設(shè)計(jì)········································································································６3。3。４JＴAG接口············································································································63.3.６串口電路·············································································································73.4軟件設(shè)計(jì)···························································································································83。4。１Ｂooｔloadｅｒ工作原理·····················································································83．４.２第一階段·············································································································93.4.１第二階段············································································································１0總結(jié)與致謝······························································································································11參考文獻(xiàn)··································································································································１2摘要串口通信是目前單片機(jī)和DSＰ等嵌入式系統(tǒng)之間,以及嵌入式系統(tǒng)與PC機(jī)或無(wú)線(xiàn)模塊之間的一種非常重要且普遍使用的通信方式。在嵌入式系統(tǒng)的硬件結(jié)構(gòu)中,通常只有一個(gè)8位或16位的ＣPU，不僅要完成主流程的工作,同時(shí)還要處理隨時(shí)發(fā)生的各種中斷，因而嵌入式系統(tǒng)中的串口通信程序設(shè)計(jì)與ＰＣ機(jī)有很大的不同。串行端口的本質(zhì)功能是作為CＰU和串行設(shè)備間的編碼轉(zhuǎn)換器,一般微機(jī)內(nèi)都配有通信適配器，使計(jì)算機(jī)能夠與其他具有RS2３２串口的計(jì)算機(jī)或設(shè)備進(jìn)行通信。本系統(tǒng)中目標(biāo)機(jī)開(kāi)發(fā)板的內(nèi)核采用的是三星的S3C２410，工作非?？煽?，可穩(wěn)定運(yùn)行在２03MHz的時(shí)鐘頻率下。其外設(shè)非常豐富，功能強(qiáng)大，完全可以滿(mǎn)足設(shè)計(jì)需要。串口線(xiàn)采用常用的RS２32型接口模式,能實(shí)現(xiàn)計(jì)算機(jī)與開(kāi)發(fā)板間的數(shù)據(jù)傳輸與控制。關(guān)鍵詞：ARM；串口通信；串行端口;RS２3２1設(shè)計(jì)目的以嵌入式芯片S3C241０為核心的最小嵌入式系統(tǒng)構(gòu)建方法，給出了S3C24１0的復(fù)位電路、電源電路、存儲(chǔ)器電路和串口電路等硬件組成。在ADS環(huán)境下自制的最小Boｏbtloａｄer程序開(kāi)發(fā)并調(diào)試。2設(shè)計(jì)要求串口通信是嵌入式設(shè)備必備的通信方式之一，選用ARＭ芯片和電平轉(zhuǎn)換芯片完成出口通信的設(shè)計(jì),并設(shè)計(jì)完整物理接口。根據(jù)設(shè)計(jì)題目的要求,選擇確定AＲM芯片型號(hào)、電平轉(zhuǎn)換芯片型號(hào)，完成系統(tǒng)硬件設(shè)計(jì)和程序設(shè)計(jì)。3設(shè)計(jì)內(nèi)容３.１S３C２410與串口通信概述3.1．１S3C241０處理器概述S3C24１０是Samsｕng公司基于ＡＲM920Ｔ?xún)?nèi)核的嵌入式微處理器．本文以S3C241０為核心，配置了最基本外圍電路構(gòu)成了最小的嵌入式系統(tǒng)，并在ADＳ上開(kāi)發(fā)了啟動(dòng)程序,完成硬件初始化，配置運(yùn)行環(huán)境，串日調(diào)試功能。Samsuｎg公司推出的1６／3２位ＲIＳC處理器S3Ｃ24１0A，為手持設(shè)備和一般類(lèi)型應(yīng)用提供了低價(jià)格、低功耗、高性能小型微控制器的解決方案。為了降低整個(gè)系統(tǒng)的成本,S3C2４１０Ａ提供了以下豐富的內(nèi)部設(shè)備:分開(kāi)的16KB的指令Cache和16ＫB數(shù)據(jù)Ｃａche，MMU虛擬存儲(chǔ)器管理，ＬＣD控制器（支持ＳTN&TFＴ），支持NANＤFlasｈ系統(tǒng)引導(dǎo)，系統(tǒng)管理器（片選邏輯和SDＲＡM控制器),3通道UＡＲT，4通道DMA，4通道PWＭ定時(shí)器，I／O端口,RTC，8通道10位ＡDC和觸摸屏接口，IIＣ－BUＳ接口,IIC-BＵS接口，USB主機(jī)，USB設(shè)備,SD主卡&ＭMＣ卡接口，2通道的SＰI以及內(nèi)部ＰLL時(shí)鐘倍頻器.S３C2410Ａ采用了ARＭ92０T內(nèi)核,0．1８um工藝的CMＯＳ標(biāo)準(zhǔn)宏單元和存儲(chǔ)器單元.它的低功耗、精簡(jiǎn)和出色的全靜態(tài)設(shè)計(jì)特別適用于對(duì)成本和功耗敏感的應(yīng)用。同樣它還采用一種叫做AｄvａnｃedMicroｃoｎｔrｏlｌeｒBｕsAｒchiteｃtuｒｅ(ＡMBA）新型總線(xiàn)結(jié)構(gòu).Ｓ3Ｃ2４10Ａ的顯著特性是它的CPＵ核心，是一個(gè)由AdvancedRISCMachｉnes（AＲM)有限公司設(shè)計(jì)的16/32位ＡＲM920TRIＳC處理器。AＲM92０T實(shí)現(xiàn)了MMU，ＡMBABUS和Hａrvａrd高速緩沖體系結(jié)構(gòu)。這一結(jié)構(gòu)具有獨(dú)立的16KＢ指令Cachｅ和１６KB數(shù)據(jù)Cache,每個(gè)都是由８字長(zhǎng)的行(lｉne）構(gòu)成。通過(guò)提供一系列完整的系統(tǒng)外圍設(shè)備，S３C2410A大大減少了整個(gè)系統(tǒng)的成本，消除了為系統(tǒng)配置額外器件的需要.本文檔將介紹S3C241０Ａ中集成的以下片上功能：●1．8Ｖ/2.0V內(nèi)核供電,３。３Ｖ存儲(chǔ)器供電,３.3V外部I/O供電；●具備16ＫB的I－Cａｃｈｅ和１6KＢ的D-Cacｈe／MMU;●外部存儲(chǔ)控制器（SDＲＡM控制和片選邏輯)●LCD控制器（?大支持4K色STN和256K色TＦT）提供1通道ＬCＤ專(zhuān)用ＤＭA.●4通道DMA并有外部請(qǐng)求引腳.●3通道UAＲＴ(IrＤＡ1。0，1６字節(jié)ＴxFIFO，和16字節(jié)ＲxFIFO）/２通道ＳPI●1通道多主ＩIC—BUS/1通道IIS-BUＳ控制器.●兼容ＳＤ主接口協(xié)議1。０版和MMＣ卡協(xié)議2.11兼容版?！瘢捕丝赨SB主機(jī)/1端口USＢ設(shè)備(１。1版)●4通道PＷM定時(shí)器和1通道內(nèi)部定時(shí)器●看門(mén)狗定時(shí)器●１１7個(gè)通用I／O口和24通道外部中斷源?！窆目刂颇Ｊ剑壕哂衅胀?，慢速，空閑和掉電模式?！?通道10比特ADC和觸摸屏接口●具有日歷功能的RTC●具有PＬL片上時(shí)鐘發(fā)生器3。1。1串口通信串口通信的概念,即串口按位(ｂit)發(fā)送和接收字節(jié)通信協(xié)議是指通信雙方按照約定的數(shù)據(jù)格式、同步方式、傳送速度、傳送步驟等規(guī)程來(lái)進(jìn)行數(shù)據(jù)傳輸本次采用異步通信，其特點(diǎn)是通信雙方以一個(gè)字符（包括特定附加位）作為數(shù)據(jù)傳輸單位，且發(fā)送方傳送字符的間隔時(shí)間是不定的。在傳輸一個(gè)字符時(shí)總是從起始位開(kāi)始,以停止位結(jié)束。如圖1所示：圖1串行數(shù)據(jù)幀格式S3Ｃ24１0的ＵＡRT提供3個(gè)獨(dú)立的異步串行通信端口,每個(gè)端口可以基于中斷或者ＤMA進(jìn)行操作。換句話(huà)說(shuō),UＡRT控制器可以在CPU和ＵＡRＴ之間產(chǎn)生一個(gè)中斷或者DMA請(qǐng)求來(lái)傳輸數(shù)據(jù)。UＡＲT在系統(tǒng)時(shí)鐘下運(yùn)行可支持高達(dá)2３0.4K的波特率，如果使用外部設(shè)備提供的UEXTCLK，UART的速度還可以更高。每個(gè)UAＲＴ通道各含有兩個(gè)16位的接收和發(fā)送ＦIFO.S３C2410的UAＲT包括可編程的波特率，紅外接收/發(fā)送，一個(gè)或兩個(gè)停止位插入，5—8位數(shù)據(jù)寬度和奇偶校驗(yàn).每個(gè)UＡＲT包括一個(gè)波特率發(fā)生器、一個(gè)發(fā)送器、一個(gè)接收器和一個(gè)控制單元,如圖１1-１所示。波特率發(fā)生器的輸入可以是PCLK或者UEXTＣLK.發(fā)送器和接收器包含16位的ＦIFＯ和移位寄存器，數(shù)據(jù)被送入FIFO,然后被復(fù)制到發(fā)送移位寄存器準(zhǔn)備發(fā)送，然后數(shù)據(jù)按位從發(fā)送數(shù)據(jù)引腳TｘＤn輸出.同時(shí)，接收數(shù)據(jù)從接收數(shù)據(jù)引腳RxDn按位移入接收移位寄存器，并復(fù)制到FIFO。特性RｘD0,TｘD0，RxD１，TxD1，RxD2，和TｘD2基于中斷或者DMA操作ＵARTCh0，1，和2具有IｒＤＡ１．0&16字節(jié)FIＦOUARＴＣh0和1具有nＲＴS０,nＣＴS0，ｎＲTＳ１，和ｎCTS１支持發(fā)生／接收握手3．２方案設(shè)計(jì)圖2通信系統(tǒng)的組成框圖本系統(tǒng)是以嵌入式芯片Ｓ3Ｃ２41０為核心的最小嵌入式系統(tǒng)構(gòu)建方法，給出了S3C24１0的復(fù)位電路、調(diào)試接口、電源電路、存儲(chǔ)器電路和串口電路等硬件組成。3.3電路設(shè)計(jì)３．3。１電源設(shè)計(jì)S3C2４10工作時(shí)內(nèi)核需要1。８Ｖ電壓，I/O端口和外設(shè)需要3。3V電壓。ＶＤDi/ＶDDiarｍ引腳口是供S3C2410內(nèi)核的1。8Ｖ電壓；VDDａlive引腳是功能復(fù)位和端口狀態(tài)寄存器電壓．M12引腳RTＣVDD是RＴC模塊的1。８V電壓,用電池供電保證系統(tǒng)的掉電后保持實(shí)時(shí)時(shí)鐘．VDＤＯP引腳是Ｉ/O端口３。３V電壓;VDＤMOP引腳是存儲(chǔ)器I/O端口電壓;還有一系列VＳＳ引腳需要接到電源地上．3。3V電壓從SV用ＡMＳ1117－３。3轉(zhuǎn)換得到如圖3所示；1。8V從3。3V通過(guò)MIC５207-1．８轉(zhuǎn)換得到。如圖3所示。