第四周学习总结

这周主要学习了几个互联网平台架构的演进，主要是随着业务的发展一步步解决遇到的业务、性能等问题，逐步将平台打造成高并发、高可用、高度可复用的平台。



架构演进的每一步性能都会进行一定的提升，可以针对自己公司的情况，提出相应的解决方案。



如果是开发新项目，最重要的是快速上线，尽早占领市场，此时可以设计相对简单的架构。等项目上线之后根据业务的发展来决定采用什么样的架构来进行迭代升级。一旦项目运营失败，前期投入的研发成本也不会损失很多。

不过即使是新项目，也需要谨慎。如果只是听信业务尽快上线，架构过于简单，即使加班加点做到上线，等稍有用户量便出现性能问题时，作为技术部门就会很被动，这也是我见到的真实事情。

技术负责人带10多个人的团队用一个月的时间将一个平台上线，非常辛苦，也达到了业务的上线时间要求。但是一个月后，用户突然增多，平台性能无法支撑，业务都没有给技术重构的机会，最后技术负责人是含恨离职。

所以，新项目的架构不能过于复杂，但是也需要预判用户量。



对于正在运营的项目，可以根据当前遇到的性能瓶颈选择对应的解决方案。

我们正在运营的项目使用zk+dubbo做的分布式，使用MySQL主从数据库，目前的性能瓶颈在于数据库，从系统层面的优化应该是增加Redis缓存服务器，减少对数据库的直接查询。数据库另外一个方面的压力是随着业务的发展，单表的数据量增加，再加上大量连表查询的SQL导致慢查询的语句较多，可以采用增加NoSQL服务器和增加历史表，存储无效的历史数据。

代码层面的优化，代码耦合较高，很多核心业务方法比较长，难以维护。没有遵守开闭原则，考虑到业务的长期和稳定发展，也应该逐步进行解耦，和根据设计模式进行改造。



总之，胖子不是一口吃成的，随着业务发展逐步迭代升级架构，才是可持续发展的方向。