大战黑客，一路披荆斩棘，百亿互联网金融平台救火故事！

会员服务 ·

大战黑客，一路披荆斩棘，百亿互联网金融平台救火故事！

2017 年 9 月 27 日 51CTO博客 纯洁的微笑

多年前，又是周六客服打电话过来，平台官网不能访问，APP 完全无法打开，客户在 QQ 群和微信群中各种反馈，说平台是不是跑路了？客服的多条 400 热线完全被打爆，电话已经接不过来…

一直以来总是想以什么方式去记录下自己在互金行业的这段经历，趁着自己还记得清楚，还能找到一些资料原型，一方面可以分享出来供大家参考，但是更重要的是多年以后我可以根据这些文章回忆起来自己的那段激情岁月。

想了很久但一直没有实施，后来觉得应该从架构的角度来梳理一篇文章，就写了《从零到百亿互联网金融架构发展史》这篇文章。

我认为只有实战出来的东西以及解决问题的过程，才是工作中最宝贵的经验，应该把它分享出来，在梳理的过程中有三起事故和黑客攻击事件比较有代表性，之前分享过一篇《一次 DNS 缓存引发的惨案》的文章。

本文以互联网金融大战黑客开篇，来回忆我一路走过来所经历过的救火故事。

百亿互金平台大战黑客

在互联网行业里，如果你们的系统还没有被黑客们练过，说明你们的系统还不够成熟。

在以往的工作经历中，我大都做后端服务，较少经受到黑客们的光顾。但是自从 2014 年进入互联网金融行业之后，和黑客们打交道已经成了我日常工作的一部分。

2015 年是互联网金融行业受黑客攻击最多的一年，各个互金公司都深受其害，其中网贷之家有一段时间被黑客攻击的太厉害，连续几天网站都无法打开。因此部分互金公司选择了出钱消灾，这让极客们尝到了甜头，导致吸引了更多的黑客们跃跃欲试。

当然了我们也未能幸免，什么 DDOS 攻击、SQL 注入、寻找系统漏洞等几乎都被经历过了，有的黑客还比较好，应该是出于善意或者展示自己，将漏洞放到乌云上面或者漏洞盒子里面让厂商来修复。但更多的是一些黑产完全就是威胁、敲诈想捞一笔钱。

先看看下面这位吧：

这个家伙潜伏到我们公司的客户群里面，冒充我们的客户代表将头像和资料替换成一样，然后给群里所有的客服发送信息，想让客服把公司内部的后台地址发给他，想通过这种方式来寻找突破口，当然了这个算是里面的小菜鸟吧。

DDOS 攻击

DDOS 攻击我们遇到了很多次，确实也没有比较好的解决办法，最后都是通过一些笨办法来尽量的避免。

有一次我正在敲代码，客服 QQ 又闪烁了起来，还没来得及打开查看信息，客服经理电话就直接打了过来，立刻就有了一种不祥的预感，说官网打不开了，后台也登录不了。

挂了电话，我在本机进行了测试果然不行，立刻准备登录 VPN 查看服务器各项指标，结果登录不上去，马上上楼找运维经理，他也登录不上。

刚准备给机房打电话的时候，机房来电话了，说我们的一个 IP 正经历着 1G 多的流量访问，问我们是否正在做什么活动，刚话没有说完就说流量已经到 5G，不到一分钟之后流量已经到达 18G 之多。

因为我们的机房和集团共用了一个宽带入口，结果陆续的集团上面反馈他们的网站、服务也都出现了问题。

机房服务商害怕引起更大的冲击，直接把我们官网对外的 IP 封掉，集团的其他业务才慢慢都恢复了过来，我们也紧急的更换了外网 IP，重新切换了域名解析才恢复。

事后我们根据 apache 分析了日志，流量来自 N 多个不同的 IP 地址根本无法应对，因为这次攻击让领导们重视了起来，才将公司机房的网络和公司集团彻底分离，这样的话不管那方受到大流量攻击都不会相互影响。

我们也想了一些笨办法，因为上次我们更换了外网 IP 之后攻击也就停止了。那么黑客肯定是针对我们外网来攻击的，所以我们就多准备了 6 个外网 IP，当监控到对某一个外网进行攻击的时候马上切换到另一个外网地址。

就这样跟他们玩，可以起到非常有限的一点作用，如果黑客真的想跟我们玩，这个办法就像是小孩子捉迷藏。

周年庆的 DDOS 攻击

还有一次我们正在做周年庆活动，突然有人在 QQ 群里面给我们客服说了一句，叫你们的技术负责人来找我，然后我们的网站就挂了，截图如下：

网站挂掉后客服就来找我，然后我按照往常的策略处理完，之后我根据客服给我的 QQ 号码加上了那个人，他开口就来吓我，我依稀记当年的对话如下：

黑客：你是平台的技术负责人吗？

我：算是吧。

黑客：你信不信我可以让你们官网在5秒之内挂掉?

我：…（沉默，还真害怕又把官网搞挂了）

黑客：你们的官网漏洞很大。

我：如果有好的建议请您赐教。

黑客：你们的服务器是不是什么防护软件都没有装？

我：…（继续沉默，这会在想不会是那个安全厂商来推广产品的吧，当然我们基础的防护肯定有）

黑客：我们有非常多的肉鸡，想攻击谁，几秒之内肯定搞定。

我：…

黑客：我们已经给很多互联网金融行业做了渗透测试，花点钱帮买你们平安，保证以后不会在出事情。

我：…

黑客：免费的策略也有很多，比如360、百度云的安全产品可以免费低档10G左右的流量。

……(中间省略)

黑客：我说了这多，你们也是不是给包烟钱，表示表示。

……

后来我也和领导进行了商议，表示坚决不能给他们钱，不能助涨这种嚣张气焰，实在不行就选择报警！

曝光一下当年使用的假 QQ 号，刚查了下变了个头像和描述，如下：

后来我一直在想为什么 DDOS 攻击总是喜欢根据外网 IP 来攻击呢，慢慢好像是理解了。

如果针对域名来攻击的话，那不就是攻击到域名商的服务器，一般域名商比较强大，黑客不太搞的定，也确实没有必要。

当然记得前一段时间，某著名域名服务商被攻击，导致国外 Twitter 等著名的互联网公司访问中断到达半天以上，还是很严重的。但是对于我们这些小公司，倒不至于搞这么大的动作。

到底如何正确的防止 DDOS 攻击，我总结了三个方案：

第一种方案，隐藏服务器外网地址，服务器前端加 CDN 中转，免费的有百度云加速、360 网站卫士、加速乐、安全宝等。
如果资金充裕的话，可以购买高防的盾机，用于隐藏服务器真实 IP，域名解析使用 CDN 的 IP，所有解析的子域名都使用 CDN 的 IP 地址。
此外，服务器上部署的其他域名也不能使用真实 IP 解析，全部都使用 CDN 来解析。
第二种方案，买一些安全产品来进行流量清洗，主要是阿里云、腾讯云这种大厂商提供的一种服务。
第三种方案，有很多的防火墙产品声称可以防止 DDOS 攻击，但是我个人使用感觉效果非常有限。

SQL注入

我们的官网是使用 PHP 开发的，因为框架比较老旧的原因，存在着一些 SQL 注入的点，我们发现了一些并进行了修补，没想到还是被一些黑客找到了突破点，这块还是比较感谢一些黑客在漏洞盒子上面提交的 Bug，如下图：

最后我们根据提示进行了紧急修复，后来也在 WAF 防火墙配置了一些拦截 SQL 注入的策略，起到双保险的作用。

我一直在想为什么 PHP 比较容易出现 SQL 注入呢，而 Java 较少暴露出来 SQL 漏洞的情况，我估摸着有两方面的原因：

PHP 一般前端使用较多，受攻击的机会更多一些，Java 一般做为后端服务攻击的可能性会比较少。
PHP 框架较多而且很杂，很多早期的框架并没有特别考虑 SQL 注入的情况，Java 大量普及了 mybaits\hibernate 这种 orm 框架，框架本身对常见的 SQL 注入有防范的功能。
但不是说 mybaits/hibernate 框架就没有被 SQL 注入的可能，大部分场景下是 OK 的，另外参数化查询可以有效的避免 SQL 注入。

通过一段时间的学习，我发现黑客一般先使用工具对网站做整体的扫描类似 Acunetix，在根据扫描出来的漏洞做个大概的分析，但是比较深入的漏洞都需要根据网站的业务再进行调整。

比如 SQL 注入会根据页面的查询使用 sqlmap 等工具来进一步的渗透。当然我对这方面还是外行，描述的可能不够清晰。

短信攻击

验证码漏洞

我们当初有一个很小的失误，有一个程序员在 H5 的小网页中将发送短信验证码返回给了前端，最后被 Haker 发现了，他利用这个漏洞可以给任意的用户重置登录密码。

那一晚上我们几百多个用户收到了密码重置的短信，虽然黑客最终也没有改用户的密码，只是发短信玩了一把，但是对于平台来讲无形的价值（信誉度）损失不小。

短信攻击

现在的网站几乎都有发送短信或者短信验证码的功能，如果前端不做校验，Haker 会随便写一个 for 循环来发短信，一般系统的短信会进行全方位的防控。

比如：在前端加验证（字符验证码，有的是拖拽的动画）；在后端根据用户或者 IP 加限制，如果用户一分钟只可以发送一条短信，忘记密码的短信一天只能发送 10 条、一个 IP 地址限制每天只能发送 100 条短信等。

如何防范

黑客攻击公司的网站未必完全是一件坏事，一方面说明了公司已经吸引到了很多人的关注，另一方面对我们技术团队是一次检验，黑客有时候会给你带来完全不同的一种思路想法。

但是被黑客攻击而影响了业务，那就不是一件愉快的事情了，如果攻击导致频繁的出现问题，对内对外都会造成大的影响，那就是严重的事件了。安全防范是一个全面且持久的工程，也是需要在硬件和软件上都要投入的一件事情。

硬件方面

需要做好网络安全规划，机房常用的安全设备有如下三个：

VPN 服务器。主要用于运维人员通过口令可以登录到机房内网中进行日常运维工作，也可以用做不同机房网络互通，保证在特定的网络下信息传输安全。
防火墙。外网访问进入机房的第一道大门，负责三层网络的安全检测，隔离内网和外网环境，外网为非信任区，内网为信任区。
WAF 防火墙。它是最重要的安全设备之一，主要是对 Web 特有入侵方式的加强防护，如 DDOS 防护、SQL 注入、XML 注入、XSS 等。WAF 防火墙属于应用层的安全防护，我们经常遇到的黑客攻击行为，主要就靠它的防护能力。

现在的防火墙技术更新特别快，以前的防火墙都是基于特征库来进行防护的，最新一代的防火墙可以根据平台的用户行为来检测分析是否为攻击行为。

软件方面

软件方面的防护主要有两方面，一方面使用证书保证传输层的数据安全，另一方面所有对外的接口都需要做好安全规划。

HTTPS证书。在 Web 服务器部署 HTTPS 证书，保证用户在交互的过程中数据没有被篡改。
网络规划。所有非必须的服务都不要开放外网访问，需要开放外网访问的服务器仅开放需要的端口，比如常用的 80。和合作公司有数据交互或者接口调用的需求，需要绑定固定的外网访问地址。
技术选择。选择成熟的框架可以避免很多安全问题，早期的很多 PHP 框架根本就没有考虑 SQL 注入的相关问题，当初 strust2 的安全漏洞多少企业被坑。选择成熟稳定的技术体系可以避免很多低级的问题。

作为一个互联网金融平台，涉及到用户资金，任何的服务（资金）差错用户都是不可容忍的，用户不懂什么是数据库，不知道什么网络不通，就是一会看不到钱在 APP 里面展示都会觉得不安。

在已经有很多 P2P 公司跑路的前提下，用户个个已经被锻炼成为福尔摩斯侦探，每天打开 APP 查看收益，监控着平台一切。

甚至半夜升级断网十分钟，也会被用户察觉，直接就发到群里面，更有甚者直接在 QQ 群或者微信群中说你们的技术行不行！

我们常说的互联网工作经验，一方面是开发经验，但其实更重要的是处理问题的能力。那么处理问题的能力怎么来呢，就是不断的去解决问题，不断的去总结经验，其中处理生产环境中问题的经验更甚。

因为在处理生产环境问题中对个人的压力和临危应变的能力要求最高，你不但需要面临千万个用户反馈，客服不时的催促，而且旁边可能就站了 N 个领导在看着你。

一副你行不行的样子要求立刻马上解决问题，这个时候你的操作就非常重要，稍有不慎便会引发二次生产事故。

说了这么多，只是想说明，生产事故对技术综合能力要求颇高，更是锻炼处理问题能力的最佳时机！

下面给大家介绍我们从零开发到现在百亿交易量所遇到的几次关键事故，有大有小从中挑出一些比较有代表性的事件来分享。

百亿互金平台背后的关键事故

并发满标

公司系统刚上线的时候，没有经历过什么大量用户并发的考验，结果公司做了一个大的推广，涌入了一批用户来抢标，共 1000 万的标的几乎都在 10 秒之内搞定。

大概会有上万左右的用户会同时去抢标，平均每秒大概有千人左右的并发，满标控制这块没有经过大的并发测试，上来之后就被打垮了，导致的结果是什么呢？

1000 万的标的，有可能到一千零几万满标，也有可能会九百多万就满标，也就是要不就是多了一些，要不就是少了一些，就满标了。

这就会很尴尬，因为借款用户就借款一千万整，那么多出来的钱不能给用户回退，因为用户好不容易才抢上了，无端退了用户也闹。

少了也是问题，用户借款一千万，少了几十万也不行，如果缺的少了可以想办法找一些有钱的客户直接给买了，多了就必须重新放出来让用户投资，非常影响士气，这个问题困扰了我们有一段时间。

购买标的流程图，不知道大家是否能根据此图发现问题呢？

超募

为何会产生超募？在最早前的版本中没有使用乐观锁来控制，如果在最后购买的用户一单出现并发，就会出现超募。

比如最后剩余 30000 份的购买份额，因为并发量特别大，可能同时会有十几个用户拿到了剩余 30000 份余额的可购买额度，有的买 1000 份、有的买上 3000 份、有的买上 20000 份都会驱动满标，所以最后导致了超募。

针对这个问题，我们主要是引入了 memcached 乐观锁的概念（底层主要是 cas、gets 两个命令），在发标的时候存入标的总份额。

当用户购买的时候首先去锁定用户购买的份额，因为乐观锁的原因，如果同时有两个用户拿到份额的时候保证只有一个最后可以更新成功（锁定份额），（锁定份额）失败直接返回，这样就保证了在入口的时候就直接屏蔽了部分并发的请求。

少募

为何产生少募？少募是可能 1000 万的标的突然到 980 万就给满标了，这是因为在超募情况下我们完善了代码，用户一进来首先就是锁定购买份额，只有锁定购买份额才能进行下面的流程。

如果锁定购买份额失败直接返回，这样虽然保证了 1000 万份额在购买初期必须每一个用户只能锁定一份。

但是在高并发的情况下，因为购买流程中有十几个分支，每一个分支失败就会退回锁定的份额，这样就会导致这样的现象，就是可能是并发一上来，马上就满标了，过了一会进度又回退回来了。

少募主要是因为分支失败回退导致的，一方面我们分析了容易导致回退热点。因为在用户抢标的时候会给用户实时的展示标的进度，在很早的版本中直接就是存入到一个标的进度表里面，并且采用了乐观锁。

如果并发一高就频繁的更新失败导致回退，因此优化了标的进度这块，直接去掉了标的进度表，实时根据查询来展示标的进度（可以有延迟，有缓存）。

另一方面在回退份额的时候再次判断试下 memcached 的份额和标的的状态，如果份额不为零并且标的状态是满标，马上自动更新状态保证后续用户可以立即购买再次驱动满标。

做了以上的两种优化后，我们还遇到了其他的一些小问题，在不断的优化过程中，终于稳定下来；在后期版本中将考虑使用 MQ 队列或者 redis 队列来处理抢标，对用户也更合理更公平一些。

重复派息

2015 年的某一天看到一个新闻说是陆金所的一个用户发现自己银行里面突然多了很多钱，没过多久又被扣走了，然后收到陆金所那边的解释，说是给用户还本派息的时候，程序出现了问题导致还本派息两次。

当他们程序员发现了此问题后紧急进行了处理，用户当然闹了呀，然后就上了新闻，当然陆金所通道能力确实比较强可以直接从用户卡里面扣。

当大家都兴致勃勃的谈论这个话题的时候，我却有一股淡淡的忧伤，为什么呢？因为这个错误我们也犯过，具体说就是我搞的，大家不知道我当时的心理压力有多大！

事情是这样子的，我们使用的第三方支付的扣款接口不是特别的稳定，于是我们前期就对接了两种不通的扣款接口，平时前端投资的时候走一个接口，后端派息或者还本的时候走另外的一个接口。

在初期的时候扣款接口不稳定，因此在给用户跑批的时候经常会有个别用户失败，需要手动给失败的用户二次派息。

做为一个有志向的程序员当然觉得这种方式是低效的，于是将程序改造了一下，在后端派息的时候当第一种扣款失败的时候，自动再次调用第二种扣款接口进行扣款。

当时想着这种方式挺好的，各个环境测试也没有问题，上线之后监控过一段时间也运行稳定。

当我感觉一切都很美妙的时候，事故就来了，突然有一天客服反馈说有的用户说自己收到的利息感觉不对，好像是多了（真的是太感谢这个用户了），我登录后台看了一下派息的流水复核了一遍，果然利息被重复派了。

瞬间我感觉一股冷水从头而下，迅速把当天所有的用户派息记录和到期记录都进行了检查，还好只影响了 70 多个用户，导致多派息了 6 万多元。

幸亏只是派息出了问题，如果是到期的话金额会翻 N 倍，其中 70 多个人里面有几个进行了体现、几个进行了再次投资，绝大部分用户在我们发现的时候还不知情，金额也没有动。

怎么处理呢？当然不能直接就动用户的钱了，给每个重复派息的用户打电话，说明原因赠送小礼物，请求谅解后我们把重复派过的利息再次调回来。

大部分用户进行了核对之后都还是比较配合的，但是肯定有一些用户不干了，当然也不能怪客户，都是我的原因，有的客户需要上门赔礼道歉，有的客户需要公司出具证明材料，我们的老板亲自给客户打了 N 个电话被客户骂了 N 遍。

我心理压力可想而知，其中有一个客户特别难缠，各种威胁说既然到了我的账户里面肯定是我的，你们的失误不应该让他来承担，折腾了很久，还是不能怪客户。

可能会说有的互联网公司经常出现这种问题后就送给客户了，哎，我们是小公司呀！这个噱头玩不起。

到底是什么原因呢？事后进行了复盘也给领导做了汇报，平时都是首先进行派息的定时任务，过一个小时之后进行到期的定时任务。

当天的派息标的比较多，跑了一个半小时，就导致了派息和到期的两个定时任务同时进行，转账有了并发，第三方支付的接口不稳定给我们返回的失败，其实有的是成功的，这就导致了我们进行了二次的扣款尝试引发了此问题。

这个事情给我带来了非常大的教训，对于金融扣款的这种事情一定需要谨慎，那怕付款引发报警之后再人工处理，也不能盲目重试可能引发雪崩效应。

杂七杂八

还有就是其他一些零碎的问题了，记的有一次对用户的登录过程进行优化，导致有一块判断少了一个括号结果用户在那两个小时内，只要输入账户，任意密码就可以登录了。

幸好我及时发现这个问题，正是这个问题才导致了我们正式确立了规范的上线流程，为以后的上线制度建定了基础。

还有一次我们在模拟用户投资一种标的时候，留了一个入口通过 HTTP 就可以调用，测试也没有问题，有一天正好给领导演示呢，就再次用 HTTP 请求的方式在浏览器执行了一下，前端就会看到自动投标的过程。

因为生产的数据有点多，投标的过程有点长，我们为了加快进度，找了好几个人同时来执行这 HTTP 请求，导致最后出现了问题，最后发现写测试脚本的这个同事根本就没有考虑并发的情况，才导致出现了问题。

我们也做了很多的活动，记得做一个网贷之家的一个活动的时候，活动上线比较紧张，我们团队曾经连续工作超过 30 个小时（一天一夜再一天），当天晚上我 2 点左右写完程序，然后测试从 2 点到早上 9 点，最终确认没有任何问题，才进行投产。

半夜公司没有暖气，我们实在冻的不行了，就在办公室跑步，从这头跑到那头，第二天上线之后，又害怕出现问题，监控了一天，确认没有任何问题，才到下午正常下班回家，那时候真是激情满满呀。

说到做活动肯定少不了羊毛党，说哪一家互金公司没有遇到过羊毛党那很少见，而且现在的羊毛党规模简直逆天了，我们用户里面就有一个羊毛党在两三天之内邀请了六七千位用户。

如果说邀请一个用户送 1 元，那这个用户就可以搞几千块一次，而且有很多专业的网站、QQ群、微信公共账号都是他们的聚集地，哪天哪个平台有活动门清，他们写的淘羊毛操作手册有时候比我们官网的帮助文档还清晰。

所以做活动的时候要考虑特别周全，各种限制，有封顶、有预案、讲诚信，只要是符合我们活动规则的坚决按照流程走。

还有一个有趣的事情，APP 推送，一次我在公交车上就看到 xx 盒子 APP 弹出 hhhhh 的推送，这个事情我们也搞过。

因为在调试的时候生产和测试就差了一个参数，有时候开发人员不注意就把生产参数部署到 uat 环境了，测试一发送就跑到生产了，这方面只能严格按照流程管理来防止。

其实还有很多问题：Mongodb 集群和 MySQL 的同步出现的一些状况、后台大量数据查询下的 SQL 优化、Golang 使用 mapreduce 碰到的问题。

其实每次出现问题都是对团队一次非常好的锻炼机会，通过发现问题，定位问题，解决问题，再次回过头来反思这些问题；重新梳理整个环节，举一反三避免下次再次出现类似的问题。

正是因为经历这些种种的困难、考验才让团队变的更强大更稳定，也更体现了流程的重要性，更是避免再次发生类似问题。

百亿互金平台技术栈大起底

技术栈(technology stack)就是一个公司的透视镜，从某些程度上可以展示出公司的技术实力。从技术桟也可以看出整个平台的技术要素，平台大小规模等，今天来给大家分享我司的技术全家桶。

我分了五块内容来介绍我们的技术栈：前端、后端、中间件、运维和工具。我画了一个思维导图方便大家整体预览，如下图：

前端

我司的前端比较简单，主要分为了三大块：

PC前端。主要使用了 H5、JS，还有很多其他的组件，但以前两者为主。少量的使用过 angularjs，最后效果不是特别好便放弃了。
移动端。分了三块：安卓、IOS、WAP。安卓前期主要以 Java 语言为主，现在慢慢在考虑 kotlin；iOS 以 Objective-C 为主，少量使用 Swift。
WAP 又称 H5，用于微信或者手机浏览器，也是使用 HTML5、JS、少量使用了 VUE，H5 端的一些 JS 组件和 PC 会有不同，一般都有对应的替代品比如：使用 zepto 替代 jquery。
模板引擎。前期一直使用的是 Beetle，大量使用 springboot 后替换为 Thymeleaf，Thymeleaf 使用体验很不错。

后端

后端以开发语言的角度给大家介绍：

后端使用的开发语言有如下几个：

PHP。我们公司的前端的网站都是使用 PHP 开发，框架主要使用了 thinkphp，小项目试验性的用了 laravel。
Golang。主要用于大数据，使用 gin 框架，用 beego 做过一个后台。
Python。没有在公司用过，自己写小爬虫玩。
Java。公司最主要的开发语言，核心系统、支撑系统、服务组件均使用 Java 开发，下面详细介绍一下。

Java 技术栈比较多，这里挑选了几个具有代表性的来讲：

Spring。做 Java 开发的，几乎离不开 Spring 全家桶了，不需要多介绍。
Alibaba。阿里这两年非常牛逼，也开源了不少的东西，主要使用过 Dubbo 和 Druid，都很优秀。
Apache。如果说搞 Java 的离不开 Spring，那么搞开发的就离不开 Apache，我们主要使用了 commons、cxf、Zookepper 等。
Orm 框架。基本以 mybatis 为主，hibernate 和 jpa 为辅的模式。
Quartz。定时任务使用的 quartz。

中间件

这里面是比较泛的中间件集合，把相关的组件也都包含进来，主要分为：数据库、Web 容器、消息、缓存、文件服务器和安全。

数据库。业务主要使用 MySQL，需要跑批统计的离线数据由 tungsten replicator 同步到 Mongodb。
Web容器。PHP 使用的 Apache，Java 使用的 Tomcat，静态资源代理使用的是 Nginx。
消息。最开始使用 Activemq，后来架构升级全面替换为 Rabbitmq。
缓存。满标控制使用 Memcached，后端业务缓存使用 Redis。
文件服务器。最开始使用 Nginx 做图片服务器，后来上线合同就全面使用了 Fastdfs。
安全。HTTPS 证书保证传输安全，Shiro 做权限控制，Oauth 做登录认证。

运维

运维是平台的生命线，主要分为六部分：

监控。主要使用了 Zabbix 来监控服务器的各项指标，少量使用 Shell 脚本和 Crontab。
负载。使用 VIP 来做均衡负载，也就是 LVS。
CI。持续集成工具主要使用了 Jenkins。Java 依赖使用 Maven 为主，Gradle 少量使用，版本控制 SVN 为主，少量使用 Git。
服务器。线上服务器大多使用的是 Centos 6.5，少量使用 Centos 7.0。测试环境使用 Vsphere 来虚拟化。
自动化部署。这块还在研究，备选有：Puppet、Ansible、Saltstack。
网络。使用 Wireshark 做网络分析。

工具

优秀的工具可以让工作事半功倍，节省很多时间。这里分开发、测试、数据库、画图和运维五个维度来介绍：

开发 Java 常用的开发工具。Eclipse 和 idea。前两年一直使用的是 Eclipse，但 Eclipse 对 Spring Boot 支持的不够友好，后来就全面使用了 idea。
PHP 开发工具比较多，我司开发人员主要使用 phpstorm 和 zend，集成环境使用 upupw；前端使用 Web Storm 和 Sublime 3；Golang 开发工具 liteide，iOS 使用 xcode。
测试。自动化测试工具 Selenjum，性能测试使用 jmeter 或者 loadrunner，开发人员一般使用 jmeter。接口测试使用 postman；移动端测试使用 appium for Android 和 appium for iOS；抓包工具使用 firebug、MIniSniffer、Fiddler。
数据库。MySQL 数据库可视化工具常用 navicat，生产使用 Workbench，少部分开发人员使用 sqlyog 和 phpMyAdmin。Mongodb 使用 Mongo VUE，表设计用 Power Designer。
画图。架构图设计使用 Visio，也尝试过 Processon；思维导图使用 Xmind。
运维。运维工具使用 xftp 或者 SecureCRT。