腾讯开发后台（腾讯应用工程师）
腾讯开发后台（腾讯应用工程师）在做架构前，一定要明确自己的目标，然后去设计资源的分配、压力测试关键节点等。拿代码报告项目来说，它的诉求可简单描述为：【明确的目标】1、开发周期不到半年2、可支撑用户量不超过百万3、并发不超过1000 TPS
描述了中型应用在
后台开发上的一种架构思路
【中型应用场景】
一套应用或系统，主要是为项目目标服务的，应用的大小其实也视各种条件来说的。这里，我相对地称中型应用，适用于以下几种场景：
1、开发周期不到半年
2、可支撑用户量不超过百万
3、并发不超过1000 TPS
【明确的目标】
在做架构前，一定要明确自己的目标，然后去设计资源的分配、压力测试关键节点等。拿代码报告项目来说，它的诉求可简单描述为：
▼
1、TGW的三网VIP、负载均衡还是很给力的，这个接入基本上没有太大问题；
2、IDC的Web服务，承载了H5站点本身的核心内容，这个后面需要增加到多台；
3、微信/RTX认证，最简单的就是接入企业IT近年推出的智能网关，但是如果想对其中的技术有更多的了解，或者想给自己的运营的公众号吸粉，还是可以用微信推荐的标准认证，再结合it提供的GetUserIdentity接口自己实现的；
4、OSS代理，这个就是为了让IDC的机器可以访问到内网环境了，部门这边统一采用的是Blowfish/CBC/PKCS5Padding加密算法对过代理的请求增加了TICKET参数（请求源信息、打时间戳）。应当尽量减少甚至避免访问内网，但是不排除有特殊的数据，确实是要交由内网的服务去处理的（比如dayu头像、日志分析）
5、Code后台，这个就是内网业务了，在这里做任何事情都要特别小心安全问题。
【从种子到大树的取与舍】
基于一个可用的原型，需要对照着前面分析的关键技术、项目目标去对比哪些需要改进和优化，同时作为一个中型应用，还需要去思考它是不是真的需要那些高大上的东西？成本是不是太高？性能是不是够用？开发、布署、测试是否方便？
这边给出代码报告目前的后台框架，从线上运营后的结果来看，它是完全够用了，远未达到性能瓶颈，成本也比较低廉：
1、TGW服务，配置多个web服务器负载均衡
需要指出的是，TGW的会话保持是基于 “ 源IP 源Port ” 的，而我们的H5打开一般会有多请求，每次请求的端口又是随机的，所以实际上对于代码报告这种情况，TGW的会话保持是没有意义的。这也就说，客户端的身份认证信息需要带在每个客户端发出的请求里，不能只依靠服务器session（一种解决方案是session共享）
2、CDN服务，腾讯云就好
所有的js、css、图片、font、视频等资源文件都最好用CDN缓存起来。一台Web服务器如果要处理资源文件，又要解析业务请求，会导致网卡流量、TCP连接数、CPU消耗大大增加。经过测试，代码报告同样的一个页面，在使用CDN后，一台web服务器可以提高4倍的并发量。
在使用CDN服务时，需要考虑用户读取某个文件会失败的情况（这些问题一般比较难重现，又不好处理），这个时候最好能通过前端代码添加出错重加载的机制，上报前端异常的机制。
3、Web服务，对外服务核心
针对多机并存，每个web服务都实现用户的鉴权（如果是自己做鉴权集群，再分发给web，对于项目来说成本有点高，SmartPxoy是一种不错的方案），并通过cookie（需加密）、session来缓存用户状态，减少重复认证次数。
针对HTTP请求，需要制定日志规则，打印自己需要的URL请求、参数。同时，即使静态资源做了CDN，Web服务最好提供回源路径。
针对业务逻辑，所有能不用数据库的就不用数据库，最大限度地使用内存（如应用内存、Redis）。能预加载到内存的数据，就提前加载好。能多机共用的数据，则通过Redis缓存起来（如果会有写入操作，需要小心同步问题）
4、Redis服务
对于用户信息量比较多的应用来说，Redis之类的缓存非常有必要，动不动就是全表缓存。但是代码报告这种应用，并不需要太多的用户状态、用户信息存取（用户主要是看，只有少量操作）。
故并没有做Redis集群，但是代码里对Redis的依赖做了解耦，即使Redis挂了，还是可以通过文件系统、数据库来读写数据。
5、业务数据库
与Redis类似，即使挂了还是有文件系统参与，虽然效率稍低，但并不会有太大问题。数据丢失也可以从日志里恢复出来（硬盘整个坏了就没办法了，毕竟没做备份）。
但是，如果是一个对数据保存要求比较高的应用，那就最少也要做好数据库冷备。相信这块基本没有哪个正经的业务系统会不做备份的（同理，Redis除了集群，应该启用持久化配置）
6、认证服务
主要是合理地调用三方提供的接口，做好异常处理即可
7、OSS代理
相较于一台OSS代理，可以适当地增加到两台，并通过配置CL5去做负载均衡（为什么用CL5？因为真的使用简单快速，对于中小型应用来说简直是福音）
8、内网日志分析服务
位于IDC的web服务器，每台机器都会打印log，为了实现日志分析。可以选两种方式：
- 在web服务器上运行采集程序，简单处理后，通过接口上传到日志分析服务
- 由日志分析服务，定时去拉取web服务器上的日志文件，再行分析
前者需要在web服务器上多跑一个日志采集应用，有一定的性能开销；后者则把日志采集、分析服务集中在一个应用里，更便于迁移布署。
如果对日志分析实时性要求比较高的项目，更适合前者。它可以分布式地实时采集数据（因为是本地文件，速度不低），并做一些简单地处理后，把核心的数据传给日志分析服务。
如果对日志主要用于看趋势或留存，则更适合后者。一方面，定时采集可以批量处理日志信息，减少频繁的网络请求。另一方面，它不需要考虑太多的容错机制、漏包问题，即使出错误了也可以快速重新下发任务补充数据。
9、TDW存储
许多业务都使用了TDW系统作为日志长期存储，一方面是它确实便宜，另一方面它在有时间参数的条件下，查询还是挺快的。
我们可以结合日志分析服务，先把原始日志记录入到TDW中，再在TDW编写定时脚本，提取运营指标、二次统计结果等，入到自己业务的数据库，便于展示查看。
【清算关键问题】
当一个架构做完一个阶段，都应当清算一次当前现状与目标的差距，这算是一个不错的习惯：
1、鉴权
确保到Web服务上的每个请求，都要带上权限信息（静态资源一般不用）才会通过，再交由业务逻辑处理。
2、Web性能
先根据经验估计项目大概的并发量，再在单机环境下，对各个接口、H5页面分别做压测，根据压测结果、理想响应时间，来估算要布署的Web服务机器数量。
前面的架构中，完全没有专门的业务服务器，Web服务器就承担了Web与后台业务的工作。这是因为项目原因，并没有复杂的业务逻辑。但在大多数应用中，在IDC应当要布置多台业务服务器，以解放Web服务的压力。
3、高可用
借用三方模块（TGW、HAProxy、LVS……），在负载均衡的时候做集群演练。必要时增加告警模块，使机器挂掉后可以及时处理（增加机器、重启等）。可用率99.99%，这个系统就达标了。
4、数据安全
敏感信息，在传输与保存时都可能会被盗用，这时候需要加密。拿鉴权模块的RTX名来说，任何接口参数里都不应当出一明文的RTX参数值，出错返回给用户的应当是统一的信息，因为攻击者可以用参数随意试探你的系统。
对于保存在用户客户端的某些加密后的敏感信息，应当设定timestamp，当超过一定时效后，信息不再能被服务器接受。
5、日志分析
一般很多平台都有日志分析的配套可以选用了，不需要自己从头去实现，这时候成本与技术要求就很低了。就我而言，够用就好，不影响性能就行。
【写在最后】
工作时间不短了，文章不多，主要是小的技术点，感觉大家都会，而大点的又怕被PK。但是，总不能因为害怕出错就不去想、不去谈、不去问。
业界最顶尖的技术大咖
最权威的实战分享
最前沿的行业咨询
一切尽在“腾讯课堂coding学院”
欢迎感兴趣的小伙伴微信关注哦~
温馨提醒：
1、微信端搜索课程
在“腾讯课堂”官方微信里，回复你想学习的内容，即可快速找到你期待的课程哦！
2、学习方式
【电脑端】
＊可通过登录ke.qq.com进入学习；
＊可通过windows PC版QQ客户端面板上的课堂入口进入学习。
【移动端】
＊下载APP “腾讯课堂” 即可进入学习；
＊关注微信公众号或者手Q公众号“腾讯课堂”，进入学习。
（注：微信和QQ的课程报名信息独立，登录时请选择对应的登录方式）
