一个可供创业公司借鉴的API架构演进思路

正文

请到「今天看啥」查看全文

解决V1.0的问题，最简单的方式就是拆应用，加机器，加内存，换SSD。把前台、后台、定时、接口拆成4个应用，独立部署。为了解决数据库性能问题，增加多级缓存。JVM里面的localCache，分布式Redis的上线，大大降低了数据库IO。如果业务稳定了，其实这个架构我们会一直沿用下去。

付钱拉遇到的真实情况是随着业务的迅猛发展，平台的功能模块开始了爆炸式增长。各种需求层出不穷，人手也比较紧张，本着先发展后治理的思路。经过3个月的努力，终于把项目写成了一个大泥球，运行速度越来越慢，新增修改需求也越来越慢，Bug越来越不容易捉，最主要性能也扛不住了。这个时候，不改也不行了。

思考

泥球一定不好吗？如何拆解大泥球？新业务线如何避免写成大泥球？我们总结了一下，有以下几点:

• 增强业务的理解和抽象

• 增强团队协作和知识储备

• 学会挑重点，合理安排优先级

其实如果业务逻辑不是特别复杂，系统对于性能、稳定性要求不是特别高。这套简单实用的架构挺适用于小公司的快速发展的。回头有机会我们把V2.0的架构开源出来，让大家评判一下。

V1.0和V2.0 架构其实没有大多变化，主旋律是拆分解耦和加机器加缓存。这也是目前业界普遍采用的做法。那有没有更好的设计理念？

• 可以灵活的提高性能；

• 可以简单的做单元测试；

• 可以无缝升级新版本；

• 可以稳步提高开发效率；

请到「今天看啥」查看全文