Exchange Server 2016 架构前瞻

在Ignite 2015上，Exchange产品组介绍了Exchange2016的一些新功能，这里主要总结一下架构更改方面的东西，并分享给你们，其中的一些内容可能在之后不久发生更改，一切以最终发行的正式版文档为准：

附上：Exchange@Ignite2015视频集锦

在Exchange 2016当中，引入了“积木式架构”这样一种概念，移除了CAS角色，在MBX角色上添加了客户端访问这样一个服务（Client Access Service）。目的嘛，就是微软常说的简化代码，加强性能之类的……

Ex2016当中的MailBox角色：

一、负责传输逻辑

二、负责全部的处理、渲染（对邮件进行处理）、存储邮件的组件和协议

客户端没法直接链接到MBX的后端终结点；而是首先链接到客户端访问服务，而后经由客户端访问服务来进行路由（本地或远程代理）到拥有该用户邮箱数据库的活动副本的MBX服务器

Ex2016中的DAG加强：

一、建立DAG的时候再也不须要DatabaseAvailabilityGroupIpAddresses ，故障转移群集在创建的时候，不会同时在AD里面创建计算机帐户，也就是管理访问点。（Ex2013 SP1就支持这个功能：http://jaapwesselius.com/2014/11/09/cluster-administrative-access-point-and-database-availability-group/）

二、默认打开延迟滞后重播功能（-ReplayLagManageEnabled $True :https://technet.microsoft.com/zh-cn/library/dd979786(v=exchg.150).aspx）

三、基于磁盘的延迟，智能减小已经延迟滞后的数据库的复制，以保证目前的活动用户不受影响

四、数据库故障转移时间比Exchange 2013减小了33%

移除了全部的CAS组件并不会影响服务器间的通讯，服务器间通讯仍然保持在协议的层面。（跟2013的服务器间通讯其实差很少：http://blogs.technet.com/b/exchange/archive/2013/01/23/exchange-2013-server-role-architecture.aspx）

负载均衡配置不会被这种架构更改所影响。

例子：在协议的层面来看一次客户端的邮箱链接请求：

一、客户端解析了DNS命名空间到负载均衡的虚拟ip。

二、负载均衡将此链接会话分配给负载均衡池里的MBX服务器

三、MBX服务器认证请求，尔后经由活动目录进行服务发现，查询该请求，收到如下信息：

    a、邮箱版本（假设为一个Ex2016邮箱）

    b、邮箱位置信息（所属的数据库信息）

四、MBX服务器决定是代理该请求或是重定向该请求到同一个森林中的其余邮箱服务器

五、MBX服务器查询活动数据库实例管理器，得知哪一个MBX服务器拥有该邮箱的活动数据库副本

六、MBX代理该请求到拥有该邮箱活动数据库副本的MBX服务器

第六步所用的协议取决于客户端用那种协议去链接客户端访问服务（Client Access Serices）,若是客户端使用HTTP请求，那么服务器间也使用HTTP（使用自签名证书的SSL加密）。若是客户端使用IMAP或者POP，那么在服务器间使用的也是IMAP或者POP。

第六步中，若是是一个电话请求，则不会被MBX服务器进行代理，而是直接重定向到活动数据库副本所在MBX服务器。由于电话设备支持重定向，而且须要与MBX服务器上的UM服务创建直接的SIP和RTP链接。

至于为何移除CAS角色，产品组的解释是：

一、咱们但愿你全部的Exchange服务器都是相同的配置，相同的硬件，以便于你采购、维护、管理

二、咱们原本就推荐角色协同并置，以充分利用Cpu和磁盘。试想你在Ex2010环境里专门为了Hub角色单独放一台物理服务器该多浪费啊

三、因此咱们的目的是为了减小你的服务器数量……减小硬件开支……

其余关键性的增强：

增强搜索：

在Ex2016当中，在活动副本和被动副本之间的复制带宽下降了40%。这是因为本地的搜索实例将只从本地的数据库读取数据进行索引，意味着若是被动副本要更新它的索引，只须要等待复制，而后从其自身的数据库进行索引，而非每一次都去找活动副本。

另外一方面，则是改进在线模式的客户端的搜索体验（好比OWA客户端），下降其得到搜索结果的时间。当用户输入完搜索关键词以前，就开始执行多此异步磁盘读取，以缓存与关键词相关的信息；经过这样来下降查询延迟

文档协同：

在以前的Ex2013版本中，OWA已经能够在线预览office和PDF文件。Sharepoint+Office Web Apps服务器也能够实现这些功能。在office 365当中，已经彻底使用Office Web Apps来提供统一文档预览和协同编辑功能。

这个特性移植到了Ex2016上，集成office web apps服务器的Exchange2016在OWA里会拥有富文本编辑以及预览功能。

下一代Office Web App服务器将不能与Exchange服务器进行并置，因此得部署独立的Office Web App服务器场来实现这功能，这个服务器场须要独立的命名空间，以及可以保持会话关联的负载均衡器。

Exchange支持非绑定的命名空间，而Office Web App须要绑定的命名空间，（可是不会因为访问位置发生改变而改变）。因此整个架构看起来就像下图同样

可扩展性：

Ex2016引入了O365使用的REST（Representational State Transfer） API，拥有更好的开放性与灵活性。这些api容许开发者从任何平台链接，好比web、pc、移动SDK（Android、IOS、.NET）或者nodejs，ruby，python，Cordova、CORS……

被抛弃的EWS在哪哭泣……

Outlook链接：

在Exchange 2013 SP1当中，outlook链接已经默认使用MAPI over HTTP，在Ex2016当中，Mapi Over HTTP已是默认设置了；而且在此链接模型之上，加入了每用户控制，以及控制某种协议是否对外部用户可用。

注意：Ex2016再也不支持经过MAPI/CDO库直接链接，第三方产品须要迁移到EWS或者是REST APIs来访问Exchange数据。

与Exchange 2013共存：

在Ex2013当中，CAS角色只代理链接，不负责处理任何内容。因此当你在环境中引入了一台Ex2016的时候，是不须要去更改命名空间的，由于Ex2013的CAS架构彻底可以将用户请求代理给拥有该邮箱活动数据库副本的Ex2016服务器。也就是说，你能够在同一个负载均衡池里同时存在Ex2013和Ex2016，而后能够一台一台的升级13到16，加一台16，减一台13.

架构须要：

Exchange 2016只支持Windows server 2012 R2和 Windows Server 10操做系统

AD层面：     
    Windows 2008 R2 或者更新的AD服务器

Windows 2008 R2或者更新的林功能级别以及域功能级别

共存：

Exchange 2013 CU11

Exchange 2010 SP3 RU11

（这俩都没出来呢……）

最佳实践架构：

与Ex2013的PA差很少：数据中心配对之上创建DAG，DAG中的MBX服务器交错分布全部的活动数据库副本，数据库副本基于JBOD存储，每块盘4个副本，其中一个副本为延迟滞后副本。客户端经过统一的命名空间进行访问，负载均衡到整个站点。

一、Ex2016 的非绑定命名空间模型使得跨越整个数据中心的7层负载均衡在配置上不须要保持会话关联性

二、你须要在每一个数据中心中部署一个Office Web Apps场，每一个场有其独立的命名空间，负载均衡器须要打开回话关联性

三、DAG的部署再也不须要管理访问点。

四、服务器：双CPU插槽，有20-24个处理器和最高196G内存，以及带电池的写入缓存控制器

五、全部数据存储卷都被格式化为ReFS（https://technet.microsoft.com/zh-cn/library/hh831724.aspx）

总结：

Exchange 2016仍是在减小服务器角色架构复杂度和引入从O365移植的成熟的设计思想两方面下功夫。若是看过视频就知道。。几乎每一项新功能前面都会加上，we learn from O365 blablabla的……