专栏名称: 聊聊架构
在这里煮酒聊架构。
目录
相关文章推荐
字节跳动技术团队  ·  ByteBrain团队SIGMOD25 | ... ·  22 小时前  
字节跳动技术团队  ·  火山引擎:单机部署 DeepSeek-R1 ... ·  昨天  
51好读  ›  专栏  ›  聊聊架构

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

聊聊架构  · 公众号  · 架构  · 2016-12-12 11:29

正文

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


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

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


思考

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

  • 增强业务的理解和抽象

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

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

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

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

  • 可以灵活的提高性能;

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

  • 可以无缝升级新版本;

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







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