用服務幫助中國中小企業變得的更好

 
十幾年前，潘石屹的遠見卓實，知道中國的未來會隨著改革開放與世界經濟接軌的速度，將會促進更多的中小企業誕生，相應這些群體對辦公室的配套需求也會越來越高，2005年，在北京最繁華地段國貿邊上，一排排商住兩用簡易辦公樓在建外矗立時，人人都說這是一群爛尾樓，不會有人買的，也不會有人租的，但十幾年的發展，潘石屹用事實證明了他的眼光，在貴的地方也有屌絲，而且需求量高的嚇人，不夸張的說，在建外SOHO這一二十棟樓里沒有一間是空著的，每棟都擠滿了大大小小的中小企業創業者。
 
回想2005年艾銻無限在創建時也立志要為中國的中小企業提供最好的IT服務，大浪淘沙，十幾年后的今天，艾銻無限仍然堅持當初為中小企業服務的路，一直都在努力成就我們服務的每一家客戶，為他們提供最好的IT服務，從未改變過，很多從那個時候一起成長的企業，有的都上市了，有的改行了，有的關門了，但艾銻無限的初心一直都未改變：
 
首先我們覺得無論怎樣努力，中國的服務始終都有很多可以提升的空間和要創新的地方。
 
其次在IT服務這個行業，中國起步比效晚，還有很多工作需要做，需要我們把這十幾年的經驗貢獻出來支持更多像我們一樣的中小企業幫助他們成長和發展。
 
還有每一家企業在剛成立時都會滿懷信心，斗志昂揚，激情四溢，如果十幾年后的今天還能不忘初心，始終如一的在這條道上，我覺得做什么都不重要，做到什么程度也不是最重要的，有這樣的心和不變的狀態才是創業者最需要的。

我們堅信只要中國的IT外包服務商都能堅定自己選擇的這個行業，用心把服務做好，一定可以讓中國的服務走向世界，讓中國的IT服務水平和品質可以與世界那些卓越的服務企業并駕齊驅，為中國小企業提供世界級的服務，幫助中國中小企業的信息化建設及其后期的IT運維等工作，從而真正實現每一家中小企業的中國品質，中國創新，中國夢想。

 
 
一、Exchange 2016簡介

現在，CPU計算能力的成本顯著降低，不再成為約束因素。隨著此約束因素的消失，Exchange2016的主要設計目標是簡化擴展、提高硬件利用率和實現故障隔離；

在Exchange2016中，服務器角色數量減少到了兩個：郵箱服務器角色和邊緣傳輸服務器角色；

Exchange2016中的郵箱服務器包括Exchange2013郵箱和客戶端訪問服務器角色中的所有服務器組件：

• 客戶端訪問服務提供身份驗證、有限重定向和代理服務。客戶端訪問服務不執行任何數據呈現，也不提供任何常見的客戶端訪問協議：HTTP、POP和IMAP和SMTP；
• 郵箱服務包括Exchange2013郵箱服務器角色中的所有傳統服務器組件：后端客戶端訪問協議、傳輸服務、郵箱數據庫和統一消息。郵箱服務器處理此服務器上活動郵箱的所有活動；

邊緣傳輸角色通常部署在外圍網絡中，位于內部ActiveDirectory林之外，旨在最大限度地縮小Exchange部署的受攻擊面；通過處理所有面向Internet的郵件流，它還添加了抵御病毒和垃圾郵件的其他郵件保護安

全層，并可以應用郵件流規則（也稱為傳輸規則）以控制郵件流；

二、Exchange 2016 的體系結構

Exchange Server 2016 使用一個構建基塊體系結構，提供電子郵件服務，以便在各種規模的組織（從小型組織到最大規模的跨國企業）進行部署。這種體系結構如下圖所示。 具體的每個各個組成部分說明如下： 
1、服務器通信體系結構
Exchange2016服務器與過去和將來的Exchange版本之間的通信發生在協議層。不允許跨層通信。這種通信體系結構可概括為“每個服務器都是一座‘島嶼’”。這種體系結構具有以下優勢：

• 減少服務器間通信。
• 提供版本感知通信。
• 隔離故障。
• 在每個服務器內集成設計。

Exchange2016服務器之間的協議層通信如下圖所示。 2、服務器角色體系結構

Exchange2016使用郵箱服務器和邊緣傳輸服務器。

郵箱服務器

• 郵箱服務器包含用于路由郵件的傳輸服務；
• 郵箱服務器包含處理、呈現和存儲數據的郵箱數據庫；
• 郵箱服務器包含接受所有協議的客戶端連接的客戶端訪問服務。這些前端服務負責將連接路由或代理到郵箱服務器上的相應后端服務。客戶端不直接連接到后端服務；
• 郵箱服務器包含向郵箱提供語音郵件和其他電話服務功能的統一消息(UM)服務；
• Exchange管理中心(EAC)和Exchange命令行管理程序

邊緣傳輸服務器

• 邊緣傳輸服務器處理Exchange組織的所有外部郵件流；
• 邊緣傳輸服務器通常安裝在外圍網絡中，并訂閱到內部Exchange組織。當Exchange組織接收和發送郵件時，EdgeSync同步進程會向邊緣傳輸服務器提供收件人信息和其他配置信息；
• 當Exchange組織接收和發送郵件時，邊緣傳輸服務器會提供反垃圾郵件規則和郵件流規則；
• Exchange命令行管理程序；

3、高可用性體系結構
郵箱高可用性

• 數據庫可用性組(DAG)是內置于Exchange2016的高可用性站點復原框架的基本元素。DAG是一組郵箱服務器，不僅托管一組數據庫，還提供數據庫、網絡和服務器故障的數據庫級自動恢復功能。

傳輸高可用性

• 傳輸服務會為傳輸中的所有郵件創建冗余副本。此功能稱為卷影冗余。
• 傳輸服務會為所有已傳遞的郵件創建冗余副本。此功能稱為安全網絡。
• 在Exchange2016中，DAG表示傳輸高可用性邊界。您可以跨多個ActiveDirectory站點部署DAG，從而實現站點復原。
• 在Exchange2016中，要實現傳輸高可用性，不只是需要盡可能確保郵件冗余而已，因為冗余并不取決于發送郵件服務器所支持的功能。因此，便可以說，Exchange2016嘗試在郵件傳遞期間和之后保留郵件的多個副本，以確保郵件冗余。

4、客戶端訪問協議體系結構

Exchange 2016 郵箱服務器上的客戶端訪問服務負責接受所有形式的客戶端連接。客戶端訪問（前端）服務將這些連接代理到目標郵箱服務器（保留用戶郵箱的主動副本的本地服務器或遠程郵箱服務器）上的后

端服務。客戶端不直接連接到后端服務。

這種通信體系結構如下圖所示。  
客戶端使用的協議決定了用于將請求代理到目標郵箱服務器上的后端服務的協議。例如，如果客戶端使用的是HTTP連接，則郵箱服務器使用HTTP將請求代理到目標郵箱服務器（使用自簽名證書通過SSL確保安

全）。如果客戶端使用的是IMAP或POP，則所使用的協議也是IMAP或POP。

電話服務請求不同于其他客戶端連接。郵箱服務器不會代理請求，而是會將請求重定向到保留用戶郵箱的主動副本的郵箱服務器。必須有電話服務設備，才能直接使用統一消息服務在目標郵箱服務器上建立SIP

和RTP會話。

5、Exchange 2016 體系結構更改

• 服務器角色合并，在舊版Exchange中，可以在不同的計算機上安裝客戶端訪問服務器角色和郵箱服務器角色。但在Exchange 2016中，客戶端訪問服務器角色會自動作為郵箱服務器角色的一部分進行安裝，客戶端訪問服務器角色不再是單獨的安裝選項。這一更改反映了Exchange服務器角色歸置（自Exchange 2010起的推薦最佳做法）的理念。多角色Exchange服務器體系結構帶來了以下切實可見的好處：搜索功能改進，本地搜索實例現在可以從本地郵箱數據庫副本中讀取數據。因此，被動搜索實例不再需要與主動搜索實例共同協作來執行索引更新，并且與舊版Exchange相比，主動副本與被動副本之間的帶寬需求已減少了40%。此外，搜索功能現在可以在用戶完成搜索詞之前就執行多次異步磁盤讀取。這不僅能在高速緩存中填充相關信息，還能提供Web上的Outlook等聯機客戶端的次秒級搜索查詢延遲。
  • 環境中的所有Exchange服務器（所有邊緣傳輸服務器可能除外）都可以完全相同，即具有相同的硬件、配置等。這種統一性可簡化硬件的購買，以及 Exchange 服務器的維護和管理。
  • 可能需要更少的物理Exchange服務器。這不僅能降低日常維護成本，還能減少Exchange服務器許可證以及機架、占地面積和供電需求。
  • 可伸縮性得到了改善，因為要跨更多的物理計算機分布工作負荷。在故障發生期間，其余Exchange多角色服務器上的負荷只是逐步增加，這可以確保Exchange服務器上的其他功能不會受到不利影響。
  • 復原性得到了改善，因為多角色Exchange服務器可以從更多的客戶端訪問角色（或服務）故障中復原，并仍能提供服務。
• 適用于Web上的Outlook的Office Online Server Preview文檔預覽，在舊版Exchange中，Outlook Web App包含可內置預覽Office和PDF文檔的WebReady Document Viewing。在Exchange 2016中，Web上的Outlook使用Office Online Server Preview提供適用于文檔的豐富預覽和編輯功能。雖然這提供的文檔體驗與其他產品（如 SharePoint 和 Skype for Business）一致，但必須在本地環境中部署Office Online Server Preview。
• MAPI over HTTP 是Outlook連接的默認方法，MAPI over HTTP是在Exchange 2013 Service Pack 1中引入，在傳統Outlook無處不在 (RPC over HTTP)連接方法的基礎上進行了改進。在Exchange 2016中，MAPI over HTTP為默認啟用，并提供其他控件（如每個用戶啟用或禁用MAPI over HTTP的功能，以及是否向外部客戶端播發它）。