分享下我今天写的某系统的交接文档的部分内容

优雅先生 发布于 2013/06/28 19:01
阅读 1K+
收藏 3

PS:考虑到隐私问题,下面用XX系统指代这个系统(一个后台业务系统),一些表名也被隐去了。既然是展望嘛,有点点吹水在所难免,望大家指正!O(∩_∩)O

当前系统存在的缺陷和发展前景展望

   以下内容全是个人在开发过程结合自己的一些经验而得出的个人意见,仅供参考。

   一个系统最初都是很小的,但随着时间的推移系统总会发生变化,将会包含越来越多的业务处理逻辑,代码量也将越来越大。在这个演化过程中,如果还照搬初期的“代码堆叠”开发模式,系统将逐渐腐坏而不能满足后续业务需求。这时候需要重新思考系统架构以及非功能需求。只要这个系统想继续发展下去,这一步就是不可或缺的,而且这一步进行得越早,痛苦也越少(如果在代码达到海量级别,业务逻辑已经错综复杂时再去考虑这些问题,为时已晚!)。

   下面是我的一些个人见解:

  2.1 数据库水平分表和水平分表可扩展性

   经过最终分析发现虽然目前分表策略不利于扩展(主要是balance_x表,x为0到9,根据用户ID模10水平分表),但是由于每个月的数据量增长不是很大,如果增长速度不变的话那么在10年内不用考虑分表(每个balance_x表每月大概增长6300条记录,单表数据量现在大概12万,要达到百万级别还需要11.6年,当然前提是业务增长速度不变)。

   另外分析订单表发现,它每月大概增长三万八千条,现在总共有六十几万条记录。达到百万数据级别大概还需要10个月,近三年内估计会有分表需求。

   相应地订单商品表数据量增长应该比订单表稍微快一些,所以分表需求也相对会更迫切些。

   但如果确实要让分表策略可扩展,该怎么办呢?这里给个参考链接,请参考这篇文章的方法:数据库水平切分的两种思路


   2.2 可配置参数集中化管理

    可配置参数除了数据库连接字符串等信息外,还包括:日志文件路径、异常提示消息、错误码等。目前这些信息都分散在代码中。虽然目前来看问题不是太大,但随着XX系统被使用的频繁程度增加,对外提供接口越来越多,这种配置信息也会越来越多,参数集中化管理的需求将是一种必然趋势。


   2.3 日志记录和日志分析

    现在每个接口记日志都采用的是直接写磁盘文件的形式,虽然现在部分写日志采用了异步方式,但这种原始的记日志方式毫无疑问满足不了逐渐增长的业务需求。具体发展方向包括:日志分级、日志开关可配置、为不同的业务应用不同的日志记录策略(有的业务可能实时性要求比较高,这种情况不适合直接写磁盘日志,虽然采用了新开线程写日志方式,但并发量一上来,那将需要开启多少个新线程?线程开启不了就会导致要记的日志记录不了,可以考虑在内存中维护一个写日志任务队列,然后由专门的线程去取日志任务并写日志)。

   另外说到日志分析,目前XX系统几乎一片空白。问几个简单问题:

   > 哪个接口被访问最频繁?

   > 每个接口每天哪个时段被访问最频繁?

   > XX系统接口日均被调用次数?

   > 每天通过XX系统交易的订单有多少?

   > 每天通过XX系统交易的订单总金额?

   > 每天通过XX系统交易的订单主要是什么类型的订单?

   虽然我们几乎对每个接口的调用都记录了详细的日志,但是上面这些问题我们还是回答不上来。

   建议:

   > 采用PerlShell等脚本语言对日志文件进行分析,比如分析出每天各个接口调用次数

   > 现在的非结构化日志文件不太利于日志分析,可以考虑增加一种日志写入方式,将某些日志数据写入MySQL数据库,这样之后可以利用SQL进行日志分析


   2.4 异常处理框架

    现在XX系统对任何可能的任何异常都是直接throw抛出完事。调用层次一深,这非常不利于性能,也不是规范的异常用法。异常使用有几个基本原则,其中有两个:

   > 只要自己能处理的异常就尽量自己处理

   > 正常业务流程不要通过异常处理代码来实现

   现在XX系统中异常的使用方式显然已经违反了这两条原则,异常使用有点随意。需要花点心思设计下异常处理框架。


   2.5 性能优化

    性能优化是XX系统以后发展过程将会遇到的一个问题。

    具体而言需要在下面几方面着手:

   > 监控:采用脚本监控系统内存使用、记录接口从请求发起到返回响应的时间和分析异常日志以自动发现存在性能问题的接口

   > 调优:如增加MemCache缓存来缓存一些频繁被访问(通过日志分析发现)但又不常变化的数据、慢SQL

   > ...

加载中
0
中山野鬼
中山野鬼
哈,想法挺多,不知道是否纳入后续工作中。。
优雅先生
优雅先生
其实这些东西都蛮基本的,也没有什么难的
优雅先生
优雅先生
哈哈,管他呢,反正我就展望下,具体实施看他们自己了
0
0xTang
0xTang
不错啊./..........
返回顶部
顶部