互联网架构的演变过程中的问题（一）

        互联网架构的演变，这是一个老生常谈的话题，现在网上有大量这样的文章，基本都是从单机到水平拆分再到横向拆分，最后分布式架构、微服务等等。大家说的都非常的精彩，但每个公司在真正实践时却非常非常的困难。比如：服务的横向拆分中服务的边界如何划分，在数据水平拆分中很难找到一个全局的标示来进行拆分等等。今天我们就聊聊在各个阶段演变过程中需要解决那些比较重要的问题，及自己在实际工作中如何解决这些问题的。

一、单机到集群 

        这是一个比较简单和经常发生的阶段，在一个最初的小业务时都会进行单机部署，但随着业务的发展单机不能支撑整个业务的发展，最快的提升系统能力的方法就是集群化。单机到集群需要解决的问题有：负载均衡器的引入、应用的无状态化。

集群化

       负载均衡器作为互联网公司一般都会采用软负载，比如：lvs、nginx等等。这个比较简单有非常成熟的方案。

        应用无状态化：如果你的应用从最开始就是无状态的那恭喜你这一步你就可以省略了，如果你的应该不是无状态的化，那就要进行无状态改造了。无状态化也有非常多的成熟方案，比如：状态集中管理、会话的分配策略等等。这里需要注意的一点是升级过程中的问题，会有状态丢失的可能，这一点要特殊注意。

二、数据库压力比较大缓存的引入

       缓存是一个非常神奇的东西，让人又爱又恨啊，爱她，她会让你的系统处理能力大大提升，恨她，由于她的不稳定原因容易引起系统雪崩。一般在数据库压力比较大的时候第一个想到的方案都是在应用和数据层加入缓存层，来减少数据层的压力。其实引入缓存层主要是为了大大减少了数据库的访问次数，并且缓存层的数据大部分情况是在内存中，获取速度比较快。这里面有两个问题需要解决：1、一份数据存在两个地方如何保证他们的一致性，2、如果缓存失效所有压力会瞬间打入数据层，引起数据层雪崩。这两个问题不解决使用缓存相当于在系统里引入了一个随时可能爆炸的炸弹，引狼入室啊。

缓存引入

        数据一致性问题：这是一个永恒的话题，这是一个21世纪一定能完美解决的问题。好吧我们回来，一般在使用缓存的情况在新增和修改数据时会先在数据库保证修改然后在同步修改缓存的数据，但是但是如果在数据库修改完整了系统出问题了，缓存的数据没有更新成功，咋办咋办？由于缓存中有数据会在一段时间使用老数据，造成用户获取不到真正的数据，用户会蒙逼了。如果保证缓存和数据库的数据强一致性这个很难做到，不一致有个时间窗口，如果这个时间窗口足够小，并且业务可以接受，那这个问题就不存在了。所以在同步更新缓存的情况下，加入一个异步更新缓存的功能，即在数据库保存成功后同步修改缓存中的数据，然后在发送一个异步消息通知缓存有数据修改了，然后缓存会去更新数据。这样保证了同步修改失败后，在非常短的时间内可以再次修改缓存的数据。

         大量缓存失效问题：如果发生这样的问题，基本都是灾难性的。多业务肯定会有一定损失的，在发生这样的问题时，第一时间是降低业务的损失、最快的速度恢复业务。缓存的加载是需要时间的。双缓存切换，同一份数据进行两次缓存，应用使用的是实时缓存+异步更新，备份缓存是异步更新。在发送实时缓存大量失效是让应用切换实时缓存和备份缓存。备份缓存缓存了95%的数据，对业务基本无损。

双缓存

三、杜绝裸奔，监控的重要

      在系统比较简单、单一时监控非常容易，并且感觉也不是那么重要，但当系统越来越复杂，引入的元素越来越多是，会发现系统越来越难以控制。如果不引入监控，就相当于系统在裸奔。每一个环节的出错都会导致系统的雪崩，必须要能够从全局的视觉监控系统各个环节的运行情况。负载均衡的监控、应用的监控、jvm的监控、服务器的监控、缓存的监控、数据库的监控等等。监控的方式有很多，尽量采用对系统无侵入、无性能影响的监控方式，比如采用日志分析的方式。采用日志分析的方式一定要有非常好的日志打印规范，做到日志打印格式统一、日志打印无死角、日志打印可降级等等。

今天就写到这后面继续。