分布式系统设计中容易忽略的问题

俗话说：性能是程序员的软肋。但是性能好不一定重要，最重要的还是要符合业务

我这个项目已经接近尾声，总结一下我之前在系统设计中忽略的问题

1.过于注重底层的性能，忽略中间层和web层的性能。

   本次项目的上层负责配置，中间层负责负责逻辑运算，底层是对外服务的。

   因此我在开始设计时太过着重于提高并发性能了，设计底层是采用用空间换时间的思路，而把大量的工作交给中间层和上层。结果底层开发完后当时测试单机已经达到10000qps，这个非常理想。

    在项目上线初期，在大量数据时发现问题了，中间层由于需要大量的运算，性能很差，web配置完成，下发后，生效时间很长。

2.没有考虑到生产环境的复杂性。由于开发在局域网里，开发时丝毫没有考虑网络因素。

  对于一个分布式系统来说很危险。上线初期，出现配置下发时，产生很高的流量，由于生成环境的机器是和别的系统公用带宽，高的带宽流量会影响其他系统的正常服务。

   于是运维部提出需要限制带宽的需求，这个是在需求里没有提到的。

    为了解决这个问题，

    1）我首先在上层和中间层进行优化，增加判断web上的配置是否会影响到底层数据的模块，减少和底层通信和更新数据的次数。

    2）其次把通信的大量数据改为，中间增加一个展开层，先由中间层把修改的消息发到展开层，展开层把消息对应的数据进行展开，再传到底层。

       虽然要传输的数据没有减少，但是公网流量却降低了，这是因为中间层和展开层之间是公网传输，而展开层和底层是同一网段，中间层和展开层的传送只是修改的消息(数据量很小)，而展开层和底层传送大量数据，但是由于同一网段就无所谓了。

3.没有考虑到分布式系统的灾难备份策略。

  下发配置开始设计时是从上往下发送，上线时出现了一个问题，上层或者中间层挂了的话，底层就得不到更新了，另外一个不好的中间层得控制下发时是顺序还是并行，还得考虑其中有某一个连接不上怎么办。

    后来重新设计采取的是从下往上请求数据。这样的好处是底层向上请求数据，连接不上时可以连接别的机器一样能够取到数据。这个有一个缺点就是，很难控制底层什么时候生效。

4.空间换时间的问题。

    为了能提高性能采取了这种方式，带来了在上线时得大幅度修改底层。这是因为牺牲的空间太大，而换来的性能已经远远超过需求。

   1G内存最多支持10个大客户，就算性能再好，这是不符合运维的要求的。

   后来为了提供空间利用率，我重新设计底层数据结构，牺牲性能来压缩内存使用才解决这个问题