项目实战01网上交易和网站

网站相关技术点简单说明

动静分离

基本属于网站必备配置了。web服务器第一层一般都是nginx，nginx三大核心功能（动静分离，负载均衡，多站点反代）之一就是动静分离 。典型配置是

1
2
3
4

listen       443 ssl;
server_name  nav.xxxx.cn;

root         /home/xxx/WebStackPage/;# 存放静态文件的文件夹

长这样的基本就是文件服务器对应的文件夹了。

http长连接

由于http请求资源（html，图片，js，css）较多，可开启http长连接，这个nginx中也有了，开启即可。

负载均衡

一般服务器都是多组（主要是应用服务器，中小型公司静态文件服务器使用一组nginx就足够了，毕竟前面还有一层cdn挡掉了大部分请求）。这也是nginx的三大核心功能之一，典型配置

1
2
3

upstream nav{
        server 127.0.0.1:8081;
}

这里还可以指定权重和分发策略（我只用过基础等权分发，复杂的没试过，理论上不难，毕竟nginx都已经烂大街的成熟了）。

网页静态化

我们主要是通过建立数据表，保存jsp和html映射关系，然后jsp中写函数，进行转化，将jsp转为相应的html，用户看到的连接已经变成了html页面。另外还有个扫表程序，将jsp固化为html页面，这是相对落后的技术了（虽然落后，但却简单，稳定，好用，伴随着网站十多年了）。
最新的版本已经改为spring-mvc架构了，没有jsp页面了。只留下个别页面（基金净值等高频访问且复杂查询的页面）做了静态化。
需要特殊留意的是目前大多数网站都使用了cdn，html会被cdn缓存导致用户取不到最新页面，可以通过cdn中配置刷新策略进行规避。

cdn

这个不在赘述了，简单，好用，尤其是目前大多服务器都部署在云主机上。阿里云腾讯云等都集成cdn服务，只要使用其主机就可以很方便的部署上去，不需要自行购置机房建立cdn服务器。
唯一需要留意的是cdn底层使用dns解析，不同地域解析到不同ip的主机，所以配置的子域名指向必须是dns服务提供方的。如果子域名还有子子域名，则无法实现（因为子域名解析到dns服务器后，子子域名隶属于子域名，也就同时超出我们的配置范畴了）
比如：helo.wangerxiao.cn的个人博客，启用了cdn，那么其域名解析列表必然有一项

1

helo.wangerxiao.cn(cname)=>xxx.dns.tencent.com

如果我们想使用域名nihao.helo.wangerxiao.cn做其他用途，则是不可行的。

净值监控

每天开市前都要保证次日净值更新完成（一般当晚12点前就应该完成了），如果超过这个时间，会发短信，微信，或email进行通知。本身就是一个简单爬虫，后台对接了公司内部监控平台，返回的code-msg会被监控平台做简答判定后，按照配置的提现方式进行消息推送。

informatic同步

跨数据库数据同步方式，比如净值信息是IA核算的，同步给TA和我们，就是通过informatic的同步功能进行的（视图=》表）。细节不清楚，并非我们工作内容，只是知道。

乐观锁

主要是直销会涉及用户份额和金额的一些计算，有些使用了悲观锁（for update），有些是乐观锁。
悲观锁还算常见，乐观锁我还是第一次见到。其实乐观锁并不是真实的锁，而是达到锁效果的操作方式。
比如：

1
2
3
4
5
6
7
8
9

a=select amout from table01 where name='john'  
old_a=a
a++
a--
a*=
a/=
new_a=a
一系列计算后,执行
update  table01 amout=new_a where name='john' and a= old_a

这个就称为乐观锁，如果update失败呢？（返回0条）。
第一种可能：如果old_a=new_a,这时说明业务正常，继续执行就是了。
第二种可能：如果old_a！=new_a（所以此时应该update返回1条结果）但是未返回更新，说明条件中的where a= old_a 条件以及不再成立，也就是说期间 a被别人改过，所以此时应该报错，将整个事务回滚。
这波操作真的溜！！

数据库结构

主备结构。
目前互联网领域大多主从模式+读写分离。但是对于基金公司这种并不面临高并发问题，且对安全性尤为重视的行业来讲。主从模式一般实在cap中选择ap（保持可用+分区容错），牺牲c（一致性）。但对金融来讲，C基本是必选项目，基于C上，如果采用多库，写入只可能更慢（多库同时确认写入成功才会认为真正成功），所以倒不如直接使用单点库。而且金融公司很多都是使用存过来保证业务的严谨性和正确性，使用多数据库这会引发其他一系列复杂问题，依赖金融公司的技术实力解决这种较偏的问题显然不大合适（和互联网不同，对金融公司来讲，IT只是辅助，并不指望去领导IT技术革新）。
采用主备结构也是基于基金行业协会的要求（最少得有一个异地备份，多了人家也不限制），为了避免一些地震或者战争等造成数据丢失所做的严谨要求，一般都是热同步+异地备份（北京+深圳+上海等）。

session共享

使用redis+spring集成套件即可，配置下就能直接使用。
主要是避免用户被转发到其他主机上后，丢失登录信息，还需要重新登录的问题。也算是主流操作吧（如无特殊要求，随大流就对了，方便，坑少，效率高）。

日志留存

100M滚动，长期留存的。
交易历史数据好像是10年，国家法律规定的，据说是查反洗钱的。

安全

花钱请专业公司扫漏洞，扫完按照漏洞清单后我们修补，大多是软件版本，旧版有漏洞，升级新版。还有些是弱口令问题或者admin页面路径问题。
由于公司业务简单，况且也不大可能有人敢攻击基金公司站点（搞不定白费劲，搞定了蹲牢房，^_^），所以还没遇到过被恶意攻击的情况。

抢红包抽奖

用过redis第一层限制+存储过程最终控制，即使抢红包抽奖，整体并发量也不大，不需要复杂技术也能搞定。