英國政府宣布，將從 2035 年起禁止銷售汽油、柴油或混合動力的新車，比原計畫提前 5 年，以此降低燃燒化石燃料造成的二氧化碳。

英國首相 Boris Johnson 表示，各國必須採取行動應對二氧化碳的排放。在經過廣泛徵詢意見後，英國將在 2035 年停止銷售燃油車，包括汽油、柴油和混合動力車，如果在未來十多年的時間內很快地實現了燃油到清潔能源的過度，禁售令有可能更早生效。

英國是歐洲第二大汽車市場，以柴油和汽油為主的燃油動力車佔汽車總銷售量 90%，近年隨著政府大力推廣電動車，電動車在英國的市場需求持續提升，但潛在消費者仍然對充電體系的缺乏感到擔憂，同時市場銷售的電動車型號不多和定價較高阻礙更多消費者選購。 2019 年英國政府推出總額為 250 萬英鎊的補貼計畫，為更多城市街道安裝電動車充電裝備。

儘管禁售令到 2035 年才生效，但對傳統汽車廠商的影響將很快體現，目前英國汽車市場銷量占比前三的廠商為福特、福斯和 Vauxhall，電動車市場銷量占比前三則是特斯拉、三菱、BMW，傳統汽車廠商投資開發新車的週期為 7 年，這代表在未來幾年內將有更多電動車進入英國市場。

受影響較大的是德國汽車廠商，英國是德國傳統汽車廠商最大的單一出口市場，占其全球汽車銷售量 20%，電動車的研發和製造週期比傳統燃油汽車短，在電動車市場中德國汽車廠商將面臨更激烈的競爭。

（合作媒體：。首圖來源：）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

生命周期決定了IServiceProvider對象採用怎樣的方式提供和釋放服務實例。雖然不同版本的依賴注入框架針對服務實例的生命周期管理採用了不同的實現，但總的來說原理還是類似的。在我們提供的中，我們已經模擬了三種生命周期模式的實現原理，接下來我們結合“服務範圍”的概念來對這個話題做進一步講述。

一、服務範圍（Service Scope）

對於依賴注入框架採用的三種生命周期模式（Singleton、Scoped和Transient）來說，Singleton和Transient都具有明確的語義，但是Scoped代表一種怎樣的生命周期模式，很多初學者往往搞不清楚。這裏所謂的Scope指的是由IServiceScope接口表示的“服務範圍”，該範圍由IServiceScopeFactory接口表示的“服務範圍工廠”來創建。如下面的代碼片段所示，IServiceProvider的擴展方法CreateScope正是利用提供的IServiceScopeFactory服務實例來創建作為服務範圍的IServiceScope對象。

public interface IServiceScope : IDisposable
{
    IServiceProvider ServiceProvider { get; }
}

public interface IServiceScopeFactory
{
    IServiceScope CreateScope();
}

public static class ServiceProviderServiceExtensions
{
   public static IServiceScope CreateScope(this IServiceProvider provider) => provider.GetRequiredService<IServiceScopeFactory>().CreateScope();
}

任何一個IServiceProvider對象都可以利用其註冊的IServiceScopeFactory服務創建一個代表服務範圍的IServiceScope對象，後者代表的“範圍”內具有一個新創建的IServiceProvider對象（對應着接口IServiceScope的ServiceProvider屬性），該對象與當前IServiceProvider在邏輯上具有如下圖所示的“父子關係”。

如上圖所示的樹形層次結構只是一種邏輯結構，從對象引用層面來看，通過某個IServiceScope封裝的IServiceProvider對象不需要知道自己的“父親”是誰，它只關心作為根節點的IServiceProvider在哪裡就可以了。下圖從物理層面揭示了IServiceScope / IServiceProvider對象之間的關係，任何一個IServiceProvider對象都具有針對根容器的引用。

二、服務實例的提供

只有在充分了解IServiceScope對象的創建過程以及它與IServiceProvider對象之間的關係之後，我們才會對三種生命周期管理模式（Singleton、Scoped和Transient）具有深刻的認識。就服務實例的提供方式來說，它們之間具有如下的差異：

• Singleton：IServiceProvider對象創建的服務實例保存在作為根容器的IServiceProvider對象上，所以多個同根的IServiceProvider對象提供的針對同一類型的服務實例都是同一個對象。
• Scoped：IServiceProvider對象創建的服務實例由自己保存，所以同一個IServiceProvider對象提供的針對同一類型的服務實例均是同一個對象。
• Transient：針對每一次服務提供請求，IServiceProvider對象總是創建一個新的服務實例。

三、服務實例的釋放

IServiceProvider除了為我們提供所需的服務實例之外，對於由它提供的服務實例，它還肩負起回收釋放的責任。這裏所說的回收釋放與.NET Core自身的垃圾回收機制無關，僅僅針對於自身類型實現了IDisposable或者IAsyncDisposable接口的服務實例（下面簡稱為Disposable服務實例），針對服務實例的釋放體現為調用它們的Dispose或者DisposeAsync方法。IServiceProvider對象針對服務實例採用的回收釋放策略取決於採用的生命周期模式，具體策略主要體現為如下兩點：

• Singleton：提供Disposable服務實例保存在作為根容器的IServiceProvider對象上，只有在這個IServiceProvider對象被釋放的時候這些Disposable服務實例才能被釋放。
• Scoped和Transient：當前IServiceProvider對象會保存由它提供的Disposable服務實例，當自己被釋放的時候，這些Disposable服務實例就會被釋放。

綜上所述，每個作為依賴注入容器的IServiceProvider對象都具有如下圖所示的兩個列表來存放服務實例，我們將它們分別命名為“Realized Services”和“Disposable Services”，對於一個作為非根容器的IServiceProvider對象來說，由它提供的Scoped服務保存在自身的Realized Services列表中，Singleton服務實例則會保存在根容器的Realized Services列表中。如果服務實現類型實現了IDisposable或者IAsyncDisposable接口，Scoped和Transient服務實例會被保存到自身的Disposable Services列表中，而Singleton服務實例則會保存到根容器的Disposable Services列表中。

對於作為根容器的IServiceProvider對象來說，Singleton和Scoped模式對它來說是兩種等效的生命周期模式，由它提供的Singleton和Scoped服務實例會被存放到自身的Realized Services列表中，而所有需要被釋放的服務實例則被存放到Disposable Services列表中。當某個IServiceProvider對象被用於提供針對指定類型的服務實例時，它會根據服務類型提取出表示服務註冊的ServiceDescriptor對象並根據它得到對應的生命周期模式：

• 如果生命周期模式為Singleton，並且作為根容器的Realized Services列表中包含對應的服務實例，它將作為最終提供的服務實例。如果這樣的服務實例尚未創建，那麼新的服務將會被創建出來並作為提供的服務實例。這個服務實例會被添加到根容器的Realized Services列表中。如果實例類型實現了IDisposable或者IAsyncDisposable接口，創建的服務實例會被添加到根容器的Disposable Services列表中。
• 如果生命周期為Scoped，那麼IServiceProvider會先確定自身的Realized Services列表中是否存在對應的服務實例，存在的服務實例將作為最終的返回值。如果Realized Services列表不存在對應的服務實例，那麼新的服務實例會被創建出來。在作為最終的服務實例被返回之前，創建的服務實例會被添加到自身的Realized Services列表中，如果實例類型實現了IDisposable或者IAsyncDisposable接口，創建的服務實例會被添加到自身的Disposable Services列表中。
• 如果提供服務的生命周期為Transient，那麼IServiceProvider會直接創建一個新的服務實例。在作為最終的服務實例被返回之前，如果實例類型實現了IDisposable或者IAsyncDisposable接口，創建的服務實例會被添加到自身的Disposable Services列表中。

對於非根容器的IServiceProvider對象來說，它的生命周期是由“包裹”着它的IServiceScope對象控制的。從前面給出的定義可以看出IServiceScope實現了IDisposable接口，Dispose方法的執行不僅標志著當前服務範圍的終結，也意味着對應IServiceProvider對象生命周期的結束。

當代表服務範圍的IServiceScope對象的Dispose方法被調用的時候，它會調用對應IServiceProvider對象的Dispose方法。一旦IServiceProvider對象因自身Dispose方法的調用而被釋放的時候，它會從自身的Disposable Services列表中提取出所有需要被釋放的服務實例，並調用它們的Dispose或者DisposeAsync方法。在這之後，Disposable Services和Realized Services列表會被清空，列表中的服務實例和IServiceProvider對象自身會成為垃圾對象被GC回收。

四、ASP.NET Core應用

依賴注入框架所謂的服務範圍在ASP.NET Core應用中具有明確的邊界，指的是針對每個HTTP請求的上下文，也就是服務範圍的生命周期與每個請求上下文綁定在一起。如下圖所示，ASP.NET Core應用中用於提供服務實例的IServiceProvider對象分為兩種類型，一種是作為根容器並與應用具有相同生命周期的IServiceProvider對象，另一個類則是根據請求及時創建和釋放的IServiceProvider對象，我們一般將它們分別稱為ApplicationServices和RequestServices。

在ASP.NET Core應用初始化過程（即請求管道構建過程）中使用的服務實例都是由ApplicationServices提供的。在具體處理每個請求時，ASP.NET Core框架會利用註冊的一个中間件來針對當前請求創建一個代表服務範圍的IServiceScope對象，該服務範圍提供的RequestServices用來提供當前請求處理過程中所需的服務實例。一旦服務請求處理完成，IServiceScoped對象代表的服務範圍被終結，在當前請求處理過程中的Scoped服務會變成垃圾對象並最終被GC回收。對於實現了IDisposable或者IAsyncDisposable接口的Scoped或者Transient服務實例來說，在變成垃圾對象之前，它們的Dispose或者DisposeAsync方法會被調用。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

※新北清潔公司,居家、辦公、裝潢細清專業服務

系統架構設計師-軟件水平考試（高級）-論文-可靠性

前言

首先說一下為什麼這兩個月又沒消息了，因為這兩個月忙啊。

首先是接收上半年系統分析師的證書，並完成總結。其次是九月份PMP考試（4A通過，尚需努力），然後是十一月的軟考高項的考試。工作的事情就不談了，還好沒什麼私人事情需要處理。所以這兩個月沒什麼空寫博客，不過接下來應該會有一些時間來寫博客。

關於系統架構師這個分支，原本都打算完結了的。然後突然發現大家對系統架構師的論文比較感興趣，並且自從我上次透露了我有一個架構師/分析師的群后，陸陸續續不斷有人私信我加群。所以，就回過頭，再發一篇系統架構師的論文。並打算找時間，將自己系統分析師，PMP，項目管理師的知識整理出來。畢竟在過去的一年的時間，我連續通過系統架構師，系統分析師，PMP，並完成，參加了高項（雖然目前還不知道通過沒），我認為我的學習方法，知識體系等還是有一定作用的，希望對大家有所幫助。嘻嘻。

哦。差點忘了。由於我的架構師/分析師群是邀請制的，所以給你們群號，也是無法添加的。所以，如果有參加架構師/分析師的朋友，請私聊我。謝謝。

一，理論

（強調一下，圖片絕對清晰。如果看不清，請從新的頁面打開，或者下載下來）

論文

摘要：
本人於2015年11月參与浙江省某在線教育平台“外教一對一在線教育”項目，該項目為客戶提供了一對一歐美外教視頻教學，社交圈，公眾直播等功能提供全方位的軟件支撐，在該項目組中我擔任系統架構師崗位，主要負責整體架構設計與中間件選型。本文以該教育平台為例，主要討論了該系統有關可靠性方面的設計與應用，以及遇到的問題與解決方案。一方面通過負載均衡進行容錯技術中冗餘設計的實現，另一方面通過層次架構風格來明確系統結構體系，從而降低系統設計複雜度，提高系統可靠性。整個系統開發工作歷時18個月。目前，該系統已經穩定運行近一年半的時間。實踐證明，通過容錯設計，降低複雜度設計等，系統有效提高了可靠性，從而為公司業務提供持續穩定的服務支撐。

正文：
隨着國家對教育的越發重視，英語教育的市場份額逐步上升，其中用戶口語提升的需求越來越大。為此，一些公司開始提供與外國人聊天的平台。我所在公司決定從國際通訊領域進軍口語教育領域。為了這項戰略轉變，公司於2015年11月設計某在線教育平台系統（一下簡稱為“系統”）。該系統幫助人們與歐美外教進行面對面的口語交流和教學。其中隨意聊提供了一種類似QQ視頻通話，而正式課程還提供了H5互動課件與課後點評等，以提高教學質量。與此同時，還有公眾直播用於拉新，AI測試用於評定學院能力，降低成本。我參与了該項目的開發工作，擔任系統架構設計師職務，負責設計系統架構。本項目組全體成員共9人，我主要負責項目計劃制定，需求分析，整體架構設計與技術選型，以及部分底層設計。該項目的架構工作與次年2月完成，選擇了層次架構風格。整個項目耗時18個月，於2017年5月完成。
目前主流的可靠性設計技術有容錯設計，檢錯設計，降低複雜度設計等技術。容錯設計技術分為恢復塊設計，N版本程序設計和冗餘設計。其中恢復塊設計是選擇一組軟件操作作為容錯設計單元，將普通的程序塊編程恢復塊。N版本程序設計的核心是通過設計出多個模塊或不同版本，對於相同初始條件和相同輸入的操作結果，實現多數表決，防止其中某一軟件模塊/版本的故障提供錯誤的服務，以實現軟件容錯。冗餘設計是在一套完整的軟件系統之外，設計一種不同路徑，不同算法或不同實現方法的模塊或系統作為備份，在出現故障時可以使用冗餘的部分進行替換，從而維持軟件系統的正常運行。缺點是費用和資源的消耗會有所增加。檢錯技術是在軟件出現故障后能及時發現並報警。其缺點是不能自動解決故障。降低複雜度設計是因為軟件複雜性與軟件可靠性有着密切關係，是產生軟件缺陷的重要根源。在設計時考慮降低軟件的複雜性，是提高軟件可靠性的有效方法。

在了解系統需求后，我們決定聽從公司技術顧問的建議，容錯設計主要應用在冗餘設計方面，通過負載均衡，雙機容錯等機制完成冗餘設計。檢錯設計則是通過對Java異常處理機制的設計與封裝處理完成。至於降低複雜度方面，採用層次架構風格，使得系統的結構明確，立體，從而提高系統可靠性。接下來，我將從系統的冗餘設計，複雜度降低設計介紹可靠性在系統中的設計與應用，以及應用過程中遇到的問題與解決方案。

1.冗餘設計：

首先說冗餘設計，冗餘包含邏輯冗餘，數據冗餘，應用冗餘等。這裏以應用冗餘為例。為了提高系統的性能，可靠性，可拓展性等，我們採用了負載均衡技術。常見的負載均衡技術有F5硬件，LVS軟件，Nginx服務器配置等。出於便捷與成本的考慮，我們採用了Nginx服務器配置負載均衡技術。通過對Nginx服務器中upstream模塊的配置，就可以實現在多台服務器的反向代理家在負載均衡。採用負載均衡后，應用服務器集群存在Session問題無法統一的問題。解決方法有Session Sticky，Session Replication，Session數據集中存儲，Cookie Based四個方案。Session Sticky是通過確保同一個會話的請求都在同一個Web服務器上處理實現。Session Replication是增加Web服務器間會話數據的同步來保證不同Web服務器間的Session數據的一致。Cookie Based就是通過Cookie傳遞Session數據完成。經過考慮，我們採用了Session數據集中存儲。Session數據集中存儲通過令每台服務器從專門的session服務器獲取session數據來解決問題。優點是可靠性，可移植性與可拓展性的大幅提高。缺點是一方面讀寫Session數據引入了網絡操作，對數據讀取存在時延和不穩定性，但對於使用內網通信的系統並沒有太大影響。另一方面，如果Session服務器或集群出現問題，將會影響整個應用。我們通過雙機容錯機制解決該問題。除此之外，還有心跳線，看門狗等技術。限於篇幅，不再贅述。

2.降低複雜度設計：

再者就是降低複雜度設計，由於系統的複雜性和綜合性，我們決定採用層次架構風格，將系統架構分為接入層，應用層，服務層，數據層四個層次。這裏以應用層與服務層為例。應用層分為視圖層與業務邏輯層，視圖層負責App與網站的表現效果，業務邏輯層負責業務層的邏輯處理。為了解決系統日益複雜，應用日益臃腫問題，我們將系統按照應用橫向劃分，將系統劃分為課件管理系統，課程管理系統等十餘個子系統。如課件管理系統負責學員上課所用課件，有課件編輯，課件預覽，課件交互等多個功能模塊。功能模塊需調用服務層的服務支撐，如課件交互模塊需要調用stomp通信服務，實現學生與老師間課件的交互功能。另外，課件交互模塊通過對賬戶服務的調用，確立課件雙方的身份，從而明確雙方在課件交互過程中對課件交互部分的交互權限。該劃分使得系統體系變得清晰明了，極大降低系統複雜度，提高系統可靠性。應用層採用基於J2ee的MVC框架-Structs框架，主要通過Servlet和JSP技術實現。另外還有動靜分離，動態資源靜態化等，這裏不再贅述。

服務層提供通用服務。系統在應用層中按照應用橫向劃分，有效降低系統複雜度。但系統代碼仍然存在冗餘，比如用戶信息的調用在諸多應用子系統中都有相關模塊。另外應用的大小依舊十分巨大，複雜，而過小的應用劃分會增加數據庫連接數負擔，故我們提出服務化解決方案。服務化方案就是提取出各個應用的通用服務，如賬戶服務，Session服務等。出於技術成熟度與技術支持等考慮，我們最終採用了阿里的dubbo服務框架，建立服務層。開發過程中，產生了服務框架部署問題與實現服務框架的jar包和應用自身依賴的jar包衝突的問題。前者，我們通過Tomcat作為Web容器，而服務框架作為容器的一部分來解決。後者，我們通過Java的ClassLoader將服務框架自身用的類與應用的類進行隔離。除此之外，我們通過服務線程池隔離，分佈請求合併，服務調用端的流程控制來降低系統複雜度，提高系統可靠性。詳情限於篇幅，不再贅述。

最終項目成功上線，正常運行了近一年半，收到各方好評。尤其是H5課件的良好互動性，使得大量業界同行爭相模仿，改用H5製作課件。還有我們的服務化方案架構被作為許多傳統互聯網企業系統重構的經典方案。在系統的架構設計中，我們引入了層次架構的設計思想，有效地降低了維護成本，提高了系統的開放性，可擴展性，可重用性以及可移植性。當然還是存在一些問題的。如H5課件採用http協議，易被非法劫持，嵌入廣告，可以將協議修改為https來解決。還有我們採用的負載均衡算法是加權輪轉算法，過於簡單，常常出現資源分配不合理的現象，可以將算法改為加權最小連接數算法來解決。這些都是我在今後的系統設計和開發中需要注意與改進的地方，也是日後我應該努力的方向。

三，總結

這篇論文的項目，依舊是之前那片論文的項目-在線教育系統。但是其中很多技術，其實在原有項目中是沒有涉及的。

另外這篇論文與之前論文存在一個結構上的不同之處，那就是這次的核心論點只有兩個分論點。不過，第二個論點-降低複雜度設計，是通過兩個方面進行闡述的。這也算是論文中核心論點的一種回答方式。往往論文的核心論點，推薦使用三個分論點進行論述，而部分論文的核心論點就只能拆分為兩個分論點（或者，三個論點的拆分維度，自己不熟悉）。這時候就需要靈活的轉變自己的思想，將核心論點的兩個分論點氛圍主次論點回答，實際體現就是主論點兩個段落，次論點一個段落。

既然說到這裏，也說一下，如果核心論點可以拆分出多個分論點。如架構風格的層次架構完全可以拆分為接入層，應用層，服務層（基礎服務層，通用服務層，業務服務層），數據接入層，數據源等。那麼這種情況，我們完全可以從中挑選三點自己熟悉的部分，進行闡述。如果擔心這樣寫，文章顯得比較僵硬，就在相關位置寫上“此處，我們以XXX,XXX,XXX為重點，進行論述”這樣的話語即可。

附錄

早期未修改的論文：

摘要：
本人於2015年11月參与浙江省某在線教育平台“外教一對一在線教育”項目，該項目為客戶提供了一對一歐美外教視頻教學，社交圈，公眾直播等功能提供全方位的軟件支撐，在該項目組中我擔任系統架構師崗位，主要負責整體架構設計與中間件選型。本文以該教育平台為例，主要討論了該系統有關可靠性方面的設計與應用。一方面通過負載均衡與應用服務器集群實現容錯技術中冗餘設計的實現，另一方面通過建立了接入層，應用層，服務層，數據層四層層次的架構來降低明確系統結構，從而系統設計複雜度，提高系統可靠性。整個系統開發工作歷時18個月。目前，該系統已經穩定運行近一年半的時間。實踐證明，通過容錯設計，降低複雜度設計等，系統有效提高了可靠性，從而為公司業務提供持續穩定的服務支撐。

正文：
隨着國家對教育的越發重視，英語教育的市場份額逐步上升，其中用戶口語提升的需求越來越大。為此，一些公司開始提供與外國人聊天的平台。我所在公司決定從國際通訊領域進軍口語教育領域。為了這項戰略轉變，公司於2015年11月設計某在線教育平台系統（一下簡稱為“系統”）。該系統幫助人們與歐美外教進行面對面的口語交流和教學。其中隨意聊提供了一種類似QQ視頻通話，而正式課程還提供了H5互動課件與課後點評等，以提高教學質量。與此同時，還有公眾直播用於拉新，AI測試用於評定學院能力，降低成本。我參与了該項目的開發工作，擔任系統架構設計師職務，負責設計系統架構。本項目組全體成員共9人，我主要負責項目計劃制定，需求分析，整體架構設計與技術選型，以及部分底層設計。該項目的架構工作與次年2月完成，選擇了層次架構風格。整個項目耗時18個月，於2017年5月完成。

目前主流的可靠性設計技術有容錯設計，檢錯設計，降低複雜度設計等技術。容錯設計技術分為恢復塊設計，N版本程序設計和冗餘設計。其中恢復塊設計是選擇一組軟件操作作為容錯設計單元，將普通的程序塊編程恢復塊。N版本程序設計的核心是通過設計出多個模塊或不同版本，對於相同初始條件和相同輸入的操作結果，實現多數表決，防止其中某一軟件模塊/版本的故障提供錯誤的服務，以實現軟件容錯。冗餘設計是在一套完整的軟件系統之外，設計一種不同路徑，不同算法或不同實現方法的模塊或系統作為備份，在出現故障時可以使用冗餘的部分進行替換，從而維持軟件系統的正常運行。缺點是費用和資源的消耗會有所增加。檢錯技術是在軟件出現故障后能及時發現並報警。其缺點是不能自動解決故障。降低複雜度設計是因為軟件複雜性與軟件可靠性有着密切關係，是產生軟件缺陷的重要根源。在設計時考慮降低軟件的複雜性，是提高軟件可靠性的有效方法。

在了解系統需求后，我們決定聽從公司技術顧問的建議，在容錯設計，檢錯設計，降低複雜度設計三個主流方向分別作出相應處理和應用。容錯設計主要應用在冗餘設計方面，通過負載均衡，雙機容錯等機制完成冗餘設計。檢錯設計則是通過對Java異常處理機制的設計與封裝處理完成。至於降低複雜度，我們應用層次清晰的四層層次架構。通過將系統劃分為接入層，應用層，服務層，數據層，使得系統的結構明確，立體，從而降低系統複雜度。限於篇幅，接下來，我將從系統的冗餘設計，複雜度降低設計兩個方面介紹可靠性在系統中的設計與應用，以及應用過程中遇到的問題。

首先說冗餘設計，冗餘包含邏輯冗餘，數據冗餘，應用冗餘等。這裏以應用冗餘為例。一方面為了提高應用服務器性能，另一方面為了提高系統的可靠性，可拓展性等，我們採用了負載均衡技術。常見的負載均衡技術有F5硬件，LVS軟件，Nginx服務器配置等。出於便捷與成本的考慮，我們採用了Nginx服務器配置負載均衡技術。通過對Nginx服務器中upstream模塊的配置，就可以實現在多台服務器的反向代理家在負載均衡。為了提高負載均衡服務器可靠性，我們採用雙機熱備機制。但採用負載均衡后，應用服務器集群出現了Session問題無法統一的問題。解決方法有Session Sticky，Session Replication，Session數據集中存儲，Cookie Based四個方案。Session Sticky是通過確保同一個會話的請求都在同一個Web服務器上處理實現。Session Replication是增加Web服務器間會話數據的同步來保證不同Web服務器間的Session數據的一致。但一方面同步Session數據會造成網絡帶寬的開銷。另一方面，每台Web服務器都要保存所有Session數據，消耗大量內存。經過考慮，我們採用了第三種方案-Session數據集中存儲。Session數據集中存儲通過令每台服務器從專門的session服務器獲取session數據來解決問題。優點是可靠性，可移植性與可拓展性的大幅提高。缺點是一方面讀寫Session數據引入了網絡操作，對數據讀取存在時延和不穩定性，但對於使用內網通信的系統並沒有太大影響。另一方面，如果Session服務器或集群出現問題，將會影響整個應用。我們通過雙機容錯機制解決該問題。Cookie Based就是通過Cookie傳遞Session數據完成。實現簡單，但是存在如Cookie長度限制等問題。除此之外，還有心跳線，看門狗等諸多技術。限於篇幅，不再贅述。

再者就是降低複雜度設計，我們從架構風格選擇，技術選型等角度實現。由於系統的複雜性和綜合性，我們決定採用層次架構風格，將系統架構分為接入層，應用層，服務層，數據層四個層次。接入層負責多平台的接入，以及API網關，負載均衡等方面。API網關的使用使得對外資源與服務獲得統一，保持系統結構的明確，從而提高了系統可靠性。應用層分為視圖層與業務邏輯層，視圖層負責App與網站的表現效果，業務邏輯層負責業務層的邏輯處理。為了解決系統日益複雜，應用日益臃腫問題，我們將系統按照應用橫向劃分，將系統劃分為課件管理系統，課程管理系統等十餘個子系統。這樣的劃分使得系統體系變得清晰明了，極大降低系統複雜度，提高系統可靠性。應用層採用基於J2ee的MVC框架-Structs框架。服務層提供通用服務。系統在應用層中按照應用橫向劃分，有效降低系統複雜度。但系統代碼仍然存在冗餘，比如用戶信息的調用在諸多應用子系統中都有相關模塊。另外應用的大小依舊十分巨大，複雜，而過小的應用劃分會增加數據庫連接數負擔，故我們提出服務化解決方案。服務化方案就是提取出各個應用的通用服務，如賬戶服務，Session服務等。出於技術成熟度與技術支持等考慮，我們最終採用了阿里的dubbo服務框架，建立服務層。數據層涉及緩存，文件系統，數據庫，數據通知服務，搜索系統等模塊。由於用戶對數據訪問具有集中性，故我們基於Spring Cache與Redis實現緩存機制。數據訪問方面，Java已經有很多成熟技術，大致分為專用API方式，JDBC方式，給予ORM或類ORM接口方式三種。最終我們採用了成熟的ORM框架-Mybatis框架，再將框架包裝一層。這樣一方面提高系統開發效率，另一方面提高系統可移植性與可靠性。除此之外，還採用了solr作為數據層搜索引擎，數據訪問層物理部署採用Proxy方式。限於篇幅，不再贅述。

最終項目成功上線，正常運行了近一年半，收到各方好評。尤其是H5課件的良好互動性，使得大量業界同行爭相模仿，改用H5製作課件。還有我們的服務化方案架構被作為許多傳統互聯網企業系統重構的經典方案。在系統的架構設計中，我們引入了層次架構的設計思想，有效地降低了維護成本，提高了系統的開放性，可擴展性，可重用性以及可移植性。當然還是存在一些問題的。如H5課件採用http協議，易被非法劫持，嵌入廣告，可以將協議修改為https來解決。還有我們採用的負載均衡算法是加權輪轉算法，過於簡單，常常出現資源分配不合理的現象，可以將算法改為加權最小連接數算法來解決。這些都是我在今後的系統設計和開發中需要注意與改進的地方，也是日後我應該努力的方向。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

※新北清潔公司,居家、辦公、裝潢細清專業服務