本系列分为项目集成、项目部署、架构演进三个方向，后续会根据情况调整文章目录。
开源地址：https://github.com/cyq1162/Taurus.MVC
本系列第一篇：Taurus.MVC V3.0.3 微服务开源框架发布：让.NET 架构在大并发的演进过程更简单。
Taurus.MVC 微服务框架 入门开发教程：项目集成：1、服务端：注册中心、网关（提供可运行程序下载）。
Taurus.MVC 微服务框架 入门开发教程：项目集成：2、客户端：ASP.NET Core（C#）项目集成：应用中心。
Taurus.MVC 微服务框架 入门开发教程：项目集成：3、客户端：其它编程语言项目集成：应用中心。
Taurus.MVC 微服务框架 入门开发教程：项目集成：4、默认安全认证与自定义安全认证。
Taurus.MVC 微服务框架 入门开发教程：项目集成：5、统一的日志管理。
Taurus.MVC 微服务框架 入门开发教程：项目集成：6、微服务的二次开发。
Taurus.MVC 微服务框架 入门开发教程：项目部署：1、微服务应用程序常规部署实现多开，节点扩容。
Taurus.MVC 微服务框架 入门开发教程：项目部署：2、让Kestrel支持绑定多个域名转发，替代Ngnix使用。
Taurus.MVC 微服务框架 入门开发教程：项目部署：3、微服务应用程序版本升级：全站升级和局部模块升级。
Taurus.MVC 微服务框架 入门开发教程：项目部署：4、微服务应用程序发布到Docker部署（上）。
Taurus.MVC 微服务框架 入门开发教程：项目部署：5、微服务应用程序发布到Docker部署（下）。
Taurus.MVC 微服务框架 入门开发教程：项目部署：6、微服务应用程序Docker部署实现多开。
Taurus.MVC 微服务框架 入门开发教程：架构演进：1、从单应用程序简单过渡到负载均衡。
Taurus.MVC 微服务框架 入门开发教程：架构演进：2、负载均到模块拆分负载。
Taurus.MVC 微服务框架 入门开发教程：架构演进：3、模块拆分负载到多级负载均衡。
Taurus.MVC 微服务框架 入门开发教程：运行示例：https://github.com/cyq1162/Taurus.MVC.MicroService.Demo
前言：
本篇教程讲述：用Taurus.MVC 微服务架构的方式，如何来进行系统版本的升级。
下面看具体教程：
1、全功能版本升级：
比如，开发了个站点，通过引入Taurus.MVC 微服务后，初步部署成负载均衡模式，并且开了N个Web应用程序节点。
Web应用中心站点：当前V1版本：appsettings.json 微服务配置内容大体如下：
{ "AppSettings": { "MicroService.Client.Name": "www.a.com",//绑定域名 "MicroService.Client.RegUrl": "http://localhost:80",//注册中心地址 "MicroService.Client.Version": 1,//这里可以指定版本号，没默认配置号时，默认版本号为0 "MicroService.App.RunUrl": "http://localhost:0", } }
Web应用中心站点：如今，要发布V2版本，具体操作如下：
1、修改微服务配置文件，提升版本号。
2、发布新版本到服务器任意目录。
3、启动项目（N次）产生节点。
Web应用中心站点：新版本V2：appsettings.json 微服务配置内容大体如下：
{ "AppSettings": { "MicroService.Client.Name": "www.a.com",//绑定域名 "MicroService.Client.RegUrl": "http://localhost:80",//注册中心地址 "MicroService.Client.Version": 2,//这里可以指定版本号，没配置号时，默认版本号为0 "MicroService.App.RunUrl": "http://localhost:0", } }
和旧版本相比，仅是修改了版本号。
升级机制与过程说明：
1、如果版本号>原有版本号（无配置即默认0），那么将启动滑动升级。 2、滑动升级过程：
A：每启动一个新版本节点，会注销一个旧节点；
B：每个节点每次注册【5-10】秒，也会注销一个旧节点。 简而言之：如果原有10个节点，那么 1、连续开启10个新版本节点，即可逐个替换掉旧的10个节点。 2、若仅开启1个节点，每5-10秒注销一个旧节点，注销掉10个节点需要50-100秒。
补充说明：
升级后，原有程序仅是不再收到请求，并未退出程序。
如果仅是测试新版本是否可用：
可保持和原有的版本号一致：
1、直接运行即可加入负载均衡中，获得流量测试。 2、绑定其它域名，引导独立测试域名的流量进行测试。
2、指定模块版本升级：
还是原来的架构图，这里补上了节点的请求网址：
当前，系统仅对会员模块进行修改升级，并需要发布该版本。
传统方式：
按照全站升级模式，一个模块的修改，需要进行全站测试，谁也不清楚会不会影响到其它模块。
Taurus.MVC 微服务框架，提供了模块版本升级的方式：
如今，要发布仅针对会员模块升级的V2版本，具体操作如下：
1、修改微服务配置文件，仅提升会员模块版本号。
2、发布新版本到服务器任意目录。
3、启动项目（N次）产生节点。
新版本V2：appsettings.json 配置如下：
{
"AppSettings": {
"MicroService.Client.Name": "www.a.com，member|2",//绑定域名，绑定会员模块（指定版本号为2）
"MicroService.Client.RegUrl": "http://localhost:80",
"MicroService.Client.Version": 1,
"MicroService.App.RunUrl": "http://localhost:0",
}
}
流程和全量升级几乎一样，唯一不同的是配置，指定了模块拦截。
然后启动程序（节点）N次即可，最终如下图：
特别说明：
1、V1版本：仅配置了域名，版本号是1，没有模块存在时，框架会默认追回模块通配符"*"，因此所有模块版本号也是：1。 2、V2版本：仍配置域名为1，避免之前的失效，再通过优先级“|”符号指定：member版本号为2。 因此，仅将请求路径为member的会员模块，拦截转发到新版本V2版本，其它模块请求，依旧回到原有版本上。
3、新增模块版本升级怎么处理？
和模块升级的处理流程一样，通过配置模块名称和版本号，就可以拦截所有新模块的请求转入新的集群，想想就很牛逼吧。
总结：
对于Taurus.MVC 微服务框架而言，部署和升级都相当简单：
部署就是把程序往上一扔，然后就启动N次的问题。
升级也是把程序往上一扔，然后就启动N次的问题。
特别是局域模块的升级方式，使得全站向模块化部署的过渡，是那么的丝滑与自然，史无前例，细思极恐啊！
