项目实战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第一层限制+存储过程最终控制,即使抢红包抽奖,整体并发量也不大,不需要复杂技术也能搞定。

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×