正文
图片引用自technet.microsoft.com
Exchange 2010的代码同时是被用来搭建Office 365 Exchange Online云服务的第一个版本。由于Exchange 2010本身的企业版本已经能够支持大型跨国公司所需要的大规模跨地域集群，所以放进数据中心里运行的时候核心代码几乎就可以直接工作。最大的修改主要在于客户的组织目录结构的分区上，另外还有身份验证方式的改变。个人认为这个可以作为业内成功的SaaS的案例之一，真实地将一个software改成了online service，而且用的同一套代码。值得提及的一点是，这个时候微软的三大云服务部门，Azure，Bing，Office几乎是互相独立的，从数据中心基础架构到自动化部署，监控等都是各自运行自己的系统。
Exchange这样的架构在企业客户的环境下是比较容易控制的，但作为在线服务时候，由于自动化工具的不够完善，用户增长和访问峰值的变化，对各个服务器角色所需的数量和硬件配备的预估和计算就有些复杂，尤其在发生紧急情况需要failover时候需要兼顾到所有类型服务器的运行和访问模式。另外涉及到用户交互的Client Access需要遵循数据最近原则，所以用户最重得到的URL都是具体到各个数据中心的，在某些情况下甚至会改变，需要通过302重定向，proxy或者AutoDiscover等手段来作补充。
从Exchange 2013开始，虽然online和on-premise的代码还是同一份，大量的开发工作开始集中于云服务下的场景，而这个时期的架构又发生了重大的调整。首先把Client Access， Hub Transport和UM都搬到了Mailbox Server上，成为一个统一的shard，进一步强调数据就近原则，并提出了每个服务器都是孤岛的原则，要求跨节点的访问必须通过HTTP而并非RPC。这个版本里引入了一个专门用来做HTTP反向代理的部件，用来分发所有HTTP的协议，代替了之前L7硬件Load Balancer的大部分工作，也实现了URL的全球统一域名。
图片引用自technet.microsoft.com
这种设计相比之前多个server role极大地简化了部署和扩容模型，被称为“砖块”架构，用来形容每台服务器的同质化和标准化。就像盖房子只需要一种砖块一样，新的集装箱式服务器运到数据中心后可以很简单完成部署，加入集群。负载均衡也被统一和简化成基于用户数据所在的shard为核心，也就是说，当服务器上的某些进程开始有CPU或者内存压力的时候，只需要简单地将原先分配到这个shard上的一些用户无断点迁移到另一些服务器组上。当然，所谓用户所在的shard也是一个动态的概念，由于新版本部署等原因用户数据所在的物理机器其实每天都可能改变数次。在“分”了大概十年以后，数据单元的计算和存储又被“合”到了一起作为一个整体架构，回到了有点类似刚开始的状态。
