背景
一家新公司，刚开始的由于业务功能单一，往往是单台服务器，单个 web server 就提供了所有功能。使用的用户也比较少，所以为了可以快速开发迭代上线，数据也全是放入数据中，如 mysql、mongo 中。当业务增多，用户增多时，这样的系统架构就不能满足需求了。这时候就需要做系统拆分和性能优化了。
系统拆分
一般拆分系统都是按功能模块拆分，比如在一个简单的电商项目，一般购物流程是浏览商品->下单->付款->发货->评价这么几个步骤。在最初的系统里，我们为了快速的开发上线，可能所有的功能全放一个项目中实现。当商品或用户数量增多时，这样的系统架构是满足不了需求的，可能导致用户访问速度变慢，影响用户体验，直接导致用户流失。
那这时候该怎么办呐？就像公司刚开始时，一个程序员既干前端的活又干后端的活，还有做测试和运维。当业务在高速发展时，他一个人一天就算上 24 小时都是干不完的。那怎么办？招人呗。在招个前端，测试，运维，自己专心做后端的工作。
这个模式就可以搬到我们的系统中来，由以前的一个系统，拆分为多个，那怎么拆才是合适的？
这里我按功能来简单的拆分，分为用户系统、商品系统、订单系统、支付系统、物流系统和评价系统。用户系统用来提供登录和鉴权相关服务，商品系统用来提供商品相关服务，订单系统用来提供订单相关服务，支付系统用来管理支付相关服务等等。
这样一来，由以前的单台服务升级为多台服务，每台服务提供自己的服务，分担服务器压力从而提升系统响应。
当服务在遇到，服务拆分后还需要横向扩展，就是把拆分后的服务部署多台，就好比一个部门招多个人一样。它的好处是提升系统的可用性和分担服务压力，更好的为用户提供服务。
系统优化
上面我们聊到了系统拆分，实际上系统优化是和它并行的，或者说可以在系统拆分之前的。这里主要的优化是代码逻辑、慢SQL优化、部分逻辑同步转异步等等优化。
代码逻辑优化，比如删除一些不需要的代码，减少以前的多层嵌套循环，把循环的单个插入改为批量插入。主要是提升代码执行的效率，有可能是空间换时间，有可能是算法的优化等等。
慢SQL优化，系统刚开始由于数据量小，用户量也少，SQL查询感觉不到慢。当数据量和用户上去后，就会明显感觉到查询变慢。通常 SQL 优化就是给经常需要查询的字段加索引，如果可以加联合索引的优先加联合索引。索引也不是越多越好，需要额外的空间存储索引，并且会影响插入删除等性能。
同步转异步，就是通知类的消息或者短信发送什么的，不是需要强同步的，最好用消息队列异步的方式实现，这样可以提升系统的响应。
缓存
对系统优化，一个很重要的手段，就是加缓存。我们都知道内存的读取速度比硬盘快很多，通过空间换时间，来提升系统响应速度。在分布式系统中，一般使用分布式缓存，如 redis 等缓存，在使用中要主要数据一致性问题，特别是修改和删除数据时，要注意更新缓存。
除了用 redis 来缓存外，我们还可以使用本地内存来缓存一些基本不变的参数、配置等等。或者缓存访问频率很高的数据，不过要注意数据更新问题。
加了缓存，提升了系统的响应，相应的也给开发带来了复杂性，特别是数据的一致性，不过，为了系统的性能，这些复杂性也是必要的。
最后
个人觉得，最好在系统刚开始设计的时候就多想下，按大的功能模块拆开，服务之间内部调用。这样的好处是当用户增长很快的时候，基本可以快速扩容，不用急着去重构，并且服务之间解耦和逻辑清晰。
提升系统的性能主要是拆分、代码优化和加缓存等，它们也可以一起进行，也可以分开进行，可根据实际情况而定。当然，如果项目周期允许的情况下，在开始开发的时候就考虑到这些，到用户真正上来时也不慌，直接加机器就可以抵御。
PS:
清山绿水始于尘，博学多识贵于勤。
微信公众号：「清尘闲聊」。
欢迎一起谈天说地，聊代码。
