正文
解决V1.0的问题，最简单的方式就是拆应用，加机器，加内存，换SSD。把前台、后台、定时、接口拆成4个应用，独立部署。为了解决数据库性能问题，增加多级缓存。JVM里面的localCache，分布式Redis的上线，大大降低了数据库IO。如果业务稳定了，其实这个架构我们会一直沿用下去。
付钱拉遇到的真实情况是随着业务的迅猛发展，平台的功能模块开始了爆炸式增长。各种需求层出不穷，人手也比较紧张，本着先发展后治理的思路。经过3个月的努力，终于把项目写成了一个大泥球，运行速度越来越慢，新增修改需求也越来越慢，Bug越来越不容易捉，最主要性能也扛不住了。这个时候，不改也不行了。
泥球一定不好吗？如何拆解大泥球？新业务线如何避免写成大泥球？我们总结了一下，有以下几点:
-
增强业务的理解和抽象
-
增强团队协作和知识储备
-
学会挑重点，合理安排优先级
其实如果业务逻辑不是特别复杂，系统对于性能、稳定性要求不是特别高。这套简单实用的架构挺适用于小公司的快速发展的。回头有机会我们把V2.0的架构开源出来，让大家评判一下。
V1.0和V2.0 架构其实没有大多变化，主旋律是拆分解耦和加机器加缓存。这也是目前业界普遍采用的做法。那有没有更好的设计理念？
-
可以灵活的提高性能；
-
可以简单的做单元测试；
-
可以无缝升级新版本；
-
可以稳步提高开发效率；
