CMS是公司的一套用于发布内容的系统，如APP用到的广告，活动，banner，新闻等内容发布系统，且为APP提供API。
迁移之前，所有的API都是直接访问数据库，返回数据给APP，逻辑相对简单，实现起来也很easy。但是发布起来有点麻烦，需要同时更新好几台服务器的站点，完全手工复制粘贴，存在一定风险。
现在做SG迁移后，前后端分离，前端采用目前很火的vue框架，后端和API均通过sg发布到host上，采用分布式集群的方式运行。所有功能有独立的hsf服务，互不干扰。发布过程也相对简单高效了不少。
当然，上面只是我自己的理解，有错的地方，还希望同学们指出来。
做sg迁移，首先需要做的是，在配置中心配置相应的集群，节点，进程，包含一个host，三个站点(两个API，一个前端) ，站点的配置很容易，拷贝过来就是一个站点，但是很费劲，需要细心。今天就遇到了一个问题，在配置站点完成后，站点可正常浏览，但是打开各个功能模块后却显示，无效的上下文，或者是token过期。检查了配置中心，配置节点没错啊，webconfig也对啊，咋回事啊？
想了很久，后来请教了同事，才知道，token过期，一般都是因为redis连接池配置有问题。于是，赶紧从其他站点copy了一个过来对比，才发现果然如此啊。在配置的时候只关注hostid去了，却没想到redis的问题。改好后，果然不再报token过期的问题。
好吧，这算是过了一关。紧接着，按模块测试。发现模块加载不了数据，显示超时。第一反应是数据库配置有问题，检查一下果然是，好吧，第一次部署，有点不熟，安慰自己一下，实际上就是不仔细啊！！！
接下来继续，尼玛，咋回事呢？还是加载不了数据啊！
让我现在捋一捋，SG迁移的步骤：
1.新增一个HSF 和两个SG的服务容器
2.将三个容器的信息注册到配置中心，在配置中心保证hostid,以及其物理地址与服务器地址保持一致。
3.sg站点和host的配置保证几点，redis连接池地址正确，数据库地址正确、MQ地址正确
4.hsf服务和sg的配置节点已在配置中心注册(因为注册信息较多，我们通过SQL脚本来创建)
5.sg和hsf的公共服务包已发布
以上这五点应该够了，仔仔细细的核对了一番，没检查出啥毛病，但是，host仍然没有接受到前端的请求。只能未完待续了，明天再请教。
ps:这是一篇跟测试不怎么相关的记录性随笔，可能过于流水账，且问题还没得到解决，但是，不妨碍它会成为我以后工作中的一份宝贵财富，谁不是慢慢成长的呢？
----------------------------------------------------------------------------------------------------------------------------------------------------
华丽丽的分割线
今天早上又重新确认了一下问题所在，说出来真有点让人哭笑不得。原因居然是因为HOST的端口没开！！！！！！！！！！！！！
想想也是醉了！
其实也应该想到这个问题，从前端发过来的请求，后端一直没有响应，排除掉数据连接的问题，也只有端口的问题了。这个问题，也是我忽略了。这个端口之前开过且是正常运行的，所以大意了。往往越是想当然的地方，是越容易忽视！
不过，这样一捣鼓，也是好事一件，至少整个迁移的过程算是了解了，掌握了。什么事情，不自己动手做一做，永远都GET不到点子上呀。
好事！
-----------------------------------------------------------------------------------------------------------------------------------------------------
为什么要采用VUE+HSF+SG框架？
对于传统的程序 可以不用sg和hsf 把所有的逻辑写到一个站点里 提供webapi给别人调用 把业务逻辑的实现 写的站点的dll里 如果有数据库 就访问数据库，但是这样 扩展起来很难 负载均衡很难 服务治理很难 流量控制 安全控制都很难，如果系统很复杂 就会越写越困难。
采用VUE+HSF+SG后，业务抽象出多层之后 业务逻辑很清晰 模块间调用简单很多 服务能力扩展起来也很容易 直接加host就是了 平滑扩展，实际上就是实现分层，让模块更清晰化。
-----------------------------------------------------------------------------------------------------------------------------------------------------
HSF和SG的概念
对于HSF 来说 HSF服务是注册在集群里 HSF的Host也是注册在集群里 所以当发布一个HSF服务的时候 HSF的管理器（这样说不严谨 ）就会判断这个服务应该发布到自己所在集群的Host里，Host作为一个服务的容器 就会把dll 加载起来。(所以，每发布一次HSF，HOST都需要重启加载一次最新的HSF)
SG也是同样的道理 但是对于SG 来说 它不是独立的容器 是寄托在IIS之上的. 只不过，HSF是一个服务层的容器 SG是webapi层的容器。HSF是内部调用 是方法级 SG是对外提供的，可以理解为SG相当于是一个对外的接口。
