1.2. biztalk host & host instance
BizTalk Server是微软的集成和服务器连接的解决方案。BizTalk Server 已经有了六个发布版本，是个成熟的产品，提供了企业更容易地连接分离系统的解决方案。包含有超过25个多平台的适配器和强大消息基础架构。BizTalk Server 提供在企业内部以及企业外部的核心系统之间的连接。
BizTalk Server的主要用途是B2B和EAI，是微软为SOA的提供的企业级解决方案的核心产品。
BizTalk Server是企业级的解决方案，在部署方面提供了极大的伸缩性和灵活性，可以极小规模的部署，也可以很大规模的部署，并为企业级应用提供足够的高可用性。
本文关注Biztalk Server的各种部署方式，重点在大规模的部署方案。
单服务器是在一台服务器上安装biztalk、biztalk数据库和所有相关组件。这种方案没有高可用性可言，如果这台机器宕掉，一切就没了。
单服务器方案一般只在开发和测试环境使用。
前两种部署方案都没提供高可用的能力，一般不会在生产环境中使用。
Biztalk作为企业应用集成的交换中枢，通常都处于比较关键的地位，对其可靠性要求都会比较高，所以对biztalk系统的高可用性都会有要求。
先介绍一下biztalk高可用的实现方式：
高可用实现
group 是biztalk的一个重要的概念。所有biztalk server都加入到同一个group，一个group共享一套相关的数据库。下面两个是最基本的数据库：
保存biztalk group的静态特性，比如这个group包含哪些服务器，包含哪些Host，各个服务器跟Host之间的映射关系。有哪些Application，所有的orchestration、接收端口和位置、发送端口。
l biztalk messagebox数据库 - BizTalkMsgBoxDb
保存biztalk group中的各个Application中的消息订阅关系，正在运行的服务实例，正在被运行中服务实例使用中的消息，挂起的服务实例。
在安装完第一台biztalk server后，需要对biztalk进行配置，配置时选择建立新的biztalk group，这时配置过程会建立这套biztalk数据库和相应的biztalk服务。
安装后续的biztalk server后，同样要进行配置，配置时选择加入现有的biztalk group，并将数据存储指向第一台配置的biztalk group时建立的biztalk数据库。
这样，所有的biztalk server都加入到同一个biztalk group，结合biztalk的host和cluster机制，这些biztalk server就能被统一的进行监控、管理、调度，进行负载均衡和故障转移。
配置好所有的biztalk server后，就可以在任意一台biztalk server的机器上使用管理这个biztalk group。
查看一个group中有多少的biztalk server：
biztalk host是个逻辑概念，也可以称为逻辑主机，一个group中可以建立多个host。
Group中的所有的接收位置、orchestration和发送端口都需要指定由哪个host进行处理。
光指定了逻辑主机host还没用，必须要落实到host instance才能真正的起作用。
一个Host就好比是一个类，类需要实例化为一个对象才能使用。同样，某一个host需要建立了对应的后才被具体化为的服务，才能在biztalk的服务中运行接收位置、orchestration、发送端口等服务。
biztalk server administration中Host Instance菜单显示所有已经建立的host Instance：
Host跟服务器无关，但host instance跟服务器相关，建立某个host的host instance时需要指定在group中的哪台服务器上建立host instance，可以只在一台服务器上建立某个host的host instance，也可以在所有的服务器上都建立这个host的host instance。但是同一个host在同一台服务器上只能建立一个host instance。
建立在一台服务器上的一个host instance就是一个biztalk服务（BTSNTSvc.exe）：
Biztalk group配合host和可以实现biztalk服务的负载均衡和故障转移功能。
Group管理加入到这个group中的所有服务器，管理在各个服务器上建立的host instance，如果同一个host在多个服务器上建立了host instance，那么指定由这个主机处理的接收位置、orchestration、发送端口服务一旦要建立服务实例就会被均衡的分配到这几个服务器进行处理。
比如某个orchestration “MB.Integration.GDN.MainProcess”被指定为由BizGropSAPOrche Host进行处理：
而BizGropSAPOrche在BIZORCHE1、BIZORCHE2、BIZORCHE3都建立有相应的host instance：
如果有多个由MB.Integration.GDN.MainProcess流程处理的消息并发进入biztalk，biztalk会把这些消息均衡的分配给BIZORCHE1、BIZORCHE2、BIZORCHE3的Host instance进行处理。这达到了负载均衡的目的。
当group中的一台服务器宕机了，biztalk group能发现这台服务器上的host instance已经停止，在分配消息时就会避开已经宕机的服务器。这实现了故障转移的功能。
biztalk group提供了负载均衡和故障转移的功能，但是有种情况group并不适应，考虑某些接收位置，比如SAP IDOC接收端口、MSMQ接收端口，这些类型的端口跟外部系统是通过TCP/IP的长连接实现的，这样类型的端口不适合有多个客户端去连接。
如果这样的接收端口在group里，接收端口的处理host在两个服务器上建立了host instance，那么这样的接收端口会在两台服务器上同时运行，会造成两个客户端同时试图去跟服务端进行TCP/IP长连接。
这种情况我们希望，这两台服务器上的host instance不要同时运行，正常时候一台服务器的host instance运行，这台服务器宕机后，能够自动切换到另一台的服务器的host instance。
Biztalk支持windows cluster，可以把host作为windows cluster的资源加入到cluster，这样这个host的host instance就会只运行在一台服务器上，另外一台服务器上的host instance会在第一台服务器宕机后自动切换。
方案
方案
大规模部署的方案一般都会用于比较大型关键应用上，高可用是必须的。Biztalk大规模的部署必须满足biztalk相关的服务器包括biztalk服务器，sql server服务器，其中任何一台服务器宕机后都不影响系统的正常工作。
有大并发量的需求才会有大规模部署的必要。大并发量是在单台服务器或少量服务器不足以支撑这么大的并发量时，通过增加机器并行处理来达到大并发量的处理能力。对于biztalk而言，在group里增加机器是最好的办法。
内部服务
Biztalk中以下三类服务需要设置处理此服务的host，一旦指定host后，此服务将只会运行在建立了指定host的的服务器上。
一个接收位置所在的host instance启动后，接收位置就会开始运行。一个group里如果有多个运行这个接收位置的host instance同时运行，那么这个接收位置就会在多个机器上的中同时运行。
当一个消息需要路由到orchestration时，如果group中有多个处理这个orchestration的host instance存在，biztalk也只会把消息路由到其中一台服务器的host instance进行处理。
跟orchestration一样，如果group中有多个处理这个发送端口的host instance存在，一个消息只会路由到一台服务器的进行处理。
对于大规模多机部署，同一个接收位置是否可以在多台服务器上同时运行来说，接收位置可以分为以下几类：
这样的接收位置，host instance中同时运行，不需要做什么特殊处理，对实际应用没太大的影响。比如sql adapter的接收位置，一个接收sql的接收位置在多台服务器的host instance同时运行，每台服务器上的接收位置都按照设置的时间间隔进行轮询，效果相当于轮训时间间隔短了。
这样的接收位置，可以在多台服务器上的host instance中同时运行，但是需要做些处理才能更好的对外提供服务。
比如http接收位置，web services接收位置。这样的接收位置可以在多台服务器上的host instance中同时运行，但是他们宿主在各自服务器的IIS中，不同的服务器IP不同，所以他们对外的服务对外的URL是不同的，不能对外提供统一的服务地址。
需要对这些不同的IP做NLB，将对外提供IIS服务的机器加入到同一个NLB Cluster，然后对外提供一个公共虚拟IP对外提供服务，然后由NLB均衡的将外部请求分配到各个IIS接收。
这样的接收位置，不能或者不适合在多台服务器上的host instance中同时运行，一旦同时运行会出现问题。比如SAP IDOC接收端口、MSMQ接收端口，这些类型的端口跟外部系统是通过TCP/IP的长连接实现的，这样类型的端口不适合有多个客户端去连接。这样的接收位置需要把处理接收位置的Host放入windows cluster中，同时只能有一个Host instance在运行，保证只有一个这样的接收位置在运行。
下面是可以适应多种情况的大规模部署的一个部署图：
对上图的部署方案图，分一下几部分做相应说明：
Biztalk严重依赖于sql server数据库，biztalk系统最简功能的安装需要生成三个数据库：BizTalkMgmtDb、、BizTalkDTADb，如果安装完整了，需要的数据有十几个之多。
本方案中，sql server有两台服务器，按照AA cluster安装，即安装两个群集的sql server实例。将使用最频繁的BizTalkMsgBoxDb数据库放在一个单独的实例中，同时也给这个sql实例分配一个单独的存储。另一个sql实例容纳其余的所有数据库。将两个sql server实例分别运行在不同的服务器上，让两台服务器同时在为sql server服务，同时群集的sql server实例还具有故障转移功能，这两台sql server中任何一台宕机后另外一台都会接手两个sql server的实例继续运行。
当然，还可以增加sql server的数量，增加sql server的实例，将数据库分散到新增的sql server服务器上，继续增加数据库的吞吐能力。
服务
Biztalk依赖于Enterprise Single Sign-On服务，因为biztalk端口的配置参数是保存在ESSO的数据库SSODB中的。端口配置在ESSO数据库中以加密形式保存，需要使用主密钥解密后使用。当biztalk服务启动后，首先通过本机的ESSO服务到Master Secret Server获取主密钥，才能获得端口的配置。
主密钥服务负责为ESSO服务提供主密钥。主密钥保存在主密钥服务所在机器的注册表中。
Biztalk服务运行依赖ESSO服务器，所有biztalk服务运行的机器上必须要有ESSO服务的运行，主密钥服务器可以在其他服务器。所以一般将主密钥服务器做群集放在非biztalk服务器上，提供主密钥服务器的高可用。
本方案中，主密钥服务放在sql server群集的两台机器上，同样做了主密钥服务的群集，所有biztalk服务器都从群集后的主密钥服务器获取主密钥。
Biztalk通过group来做大并发消息的负载均衡和故障转移，加入到同一个group的所有服务器共享一套biztalk数据库，由group统一管理，管理消息的均衡路由到不同的服务器，管理host instance的启停，管理消息不会被路由到已经停止host instance的服务器。
本方案首先将所有的biztalk服务器都加入到group中，至于host instance在这些服务器上怎么建根据实际情况，最大限度可以把所有的host在每个服务器上都建一个host instance，这样服务器的资源利用率最高。
比如一个业务流程指定由某个host处理。如果只在一台biztalk服务器上建立这个host的instance，那么biztalk只会把消息路由到建立了host instance的服务器上，一个服务器上的host instance就是一个biztalk服务（BTSNTSvc.exe），它可以使用的资源是有限的，所以一个host instance的处理能力是有限的，可能这个host instance在一台服务器上对这个业务流程的处理能力就是1秒钟20条，如果这个业务流程的实际并发量超过一秒20条，这时这台服务器就不能及时处理进来的消息。
再在group中的一台biztalk服务器上建立这个host的host instance，就变成两台biztalk服务器都有这个host的instance，group会将发送给这个业务流程处理的消息均衡的路由到这两个服务器的host instance进行处理（接收端口接收消息很快，一般不会成为消息处理能力的瓶颈），对这个消息的处理能力就会增加到每秒40条。这就是biztalk group的并行扩展能力。
可以将group中的一些biztalk服务器建立windows cluster，将biztalk host作为cluster资源加入到windows cluster，让在cluster中的相同的host instance同时只有一个在运行。
本方案将两台biztalk服务器建立windows cluster，建立两个host，host1和host2,。这两个host在biztalk中配置为cluster，分别加入到windows cluster中新建的两个empty service or application中，host1和host2组成了biztalk的Active-Active cluster，可以host1的host instance运行在一台biztalk服务器上，host2的host instance运行在cluster中的另一台biztalk服务器上。Host1运行不适合同时运行的接收位置（比如SAP 的IDOC端口，MSMQ接收端口），host2运行不适合同时运行的发送端口（比如MSMQ的发送端口）。
其实一般的接收端口接收速度都很快，使用一台服务器运行也不会成为并发处理的瓶颈。 所以，通常把所有的接收端口都放在host1上运行，所有的发送端口都放在host2上运行。这样只需要在这两台服务器上安装端口的一些adapter软件，比如biztalk adapter pack，访问oracle的oracle客户端，访问SAP的SAP dll等等。其他的biztalk服务器只用来运行orchestration。
Biztalk cluster既保证了只有一个host instance在运行，只有一个客户端连接到外部系统，又保证系统的高可用性。
接收端口还有一种情况，就是http接收端口和biztalk发布的web services的接收端口，这样的接收端口需要通过IIS对外公开URL来接收消息，如果在多台biztalk服务器上建立了这样的接收位置，就会有多个对外的URL，这样显然不合适。
本方案对这种情况是在需要运行http接收端口或web services的接收端口的biztalk服务器上建立NLB cluster，由NLB对外提供一个虚拟IP，由NLB均衡负载将请求发送到在NLB中的各个服务器的接收位置。