部署过程
8月初，我们从FineReport9 升至 FineReport10，过程还是碰到过许多坑
主要是卡端口这块（由于是两台服务器做集群），所以除了常规tomcat端口外，还有开放 8889, 48889, 7001, 9080, 9000 等端口，希望这块可以在集群部署页面有个提示，或者说弄个什么检测工具，直接在集群配置页面，这样用户可以直接检测哪些端口没开放。
其他没什么难度，根据官方教程走就可以了。
升级过程
为了避免升级工具可能对项目造成影响（之前模拟过一次，会遗留一部分9.0的jar包），所以本次不用升级工具，直接部署全新的，全部配置人工迁移，这部分也挺顺利的，毕竟人工配置，麻烦不困难。
目前发现的问题
1、两台服务器负载不均匀（当然这部分有可能是我们CLB配置的问题）
2、日志问题
这部分怨声最大，目前的日志是基于帆软自己的引擎，没办法迁移至mysql，这里面就产生一个问题，日志我们没法缓存到自己服务器（9.0的时候，我们自己写了etl，把数据按天汇总到我们自己的数据库，便于后续分析），10.0这条路走不通，也可以，我们换一条路，自己做了个填报CPT，读取内置的日志，然后一样按照特地维度汇总到我们自己数据库，起初以为没毛病，最近去看服务器才发现两台服务器日志是分开的，这怎么破，我每天还要安排人手工去导出两边日志去合并吗？
关键的一个大问题，官方的技术基本上也是一问三不知（日志文件在哪里：他们不清楚，后面回答我说是内置的swift引擎，没有文件，我想要是有文件的话，我看看能不能两台改成指向同个文件来解决日志分开的问题）
另外由这个日志看出来一个比较大的问题，也希望官方的产品能好好反思下，帆软现在主打什么？数据？分析？，那么为什么连自家的产品都做不好这一块，运营一个产品最主要的就是要分析每天的访问量，报表的访问量等等，虽然官方确认有支持部分日志报表，我看了下，报表确实也不错，很多值得借鉴学习的地方，但是像我们这种多台服务器集群的用户，你要我们分开来分析吗，还是说，让我们人工肉眼累加，我这边任何一款产品要上线前，我都会特别注重一个问题点，就是日志模块，因为我的成绩，推广效果，全部是这个模块说了算，所以为什么我会把帆软的日志单独缓存一套出来，便于后续我们跟踪、分析，所以我很奇怪，为什么一家做数据分析的公司，连自己的产品的日志模块都这么不用心，完全不考虑别人运营产品是需要这些数据做支持的？好了，希望官方真的能好好反思下，虽然是一个小功能，但是我觉得真的退步了，10.0，思路、初心已经退步了，你说你是主打数据分析的公司我都不信了，最多是做报表工具的公司！
3、还是日志问题，定时调度，如果任务（填报任务）失败了，是没有日志的。
4、用户同步数据集
9.0的时候，12万用户，同步花费时间是10秒以内，10.0第一次同步花费1个小时左右，后续可能在10分钟-20分钟左右，10.0说好的解决了很多大用户性能问题，我从这里没看出来有解决啥，我退一步说，这个时间我其实可以接受，但是第一天上线出现了一个严重bug，所有用户丢失，导致推广半小时后，几万用户反馈登录不了，当时找了技术，技术喊发各种日志，我也明确说了，看数据库是一直有在更新的，但是技术也没有说出10.0同步一次可能要耗费小时级别的，导致就是不断重启，最终终止上线，切换回旧版本。最后我自己尝试出来需要1个小时左右，技术才跟我说，他问测试，说10来万用户，那边测试说要40分钟左右。这里看出啥问题？技术的不专业，测试的没对接，没有将测试中的各种问题很好的形成文档，并且给到技术，如果当时我知道同步一次要40分钟，我就不会一直重启，还把数据库，还把整个运维团队拉过来看看是不是硬盘性能问题了。希望官方也能重视这块，针对大用户有专门的测试方案来支持，不要每次找技术都要重头沟通，然后技术重新测试。
还有其他小问题，时间问题，这里不一一赘述了，总是10.0总结为几点吧
1、稳定性好多了（当然也有可能我们换了服务器原因，直接上自己的云服务器）
2、产品功能升级，但是感觉都不特别完善（除了上诉，比如全局水印，公式显示不合法，但是实际上是可以用的），8.0感觉是最为稳定的一版（可能因为当时有1个bug100块的活动吧，解决了很多bug）
编辑于 2019-8-19 13:46
|
