软件架构设计大型网站技术架构与业务架构融合之道_余春龙著.pdf

前言为什么写本书？当我在写本书时，脑子里还会浮现当初读研究生期间一个劲儿地啃UML建模、软件架构设计书籍的情景。对于当时一个没有太多项目经历的人来说，这种理论知识显得又晦涩又抽象。但也正是这种“过早熏陶”，使得我在工作后从事的一个接一个的项目中，会去“多想”一些架构方面的事情。为什么说是“多想”了呢？稍微有些职场经验的人都知道，无论是在面试还是日常工作中，在技术方面大家更多谈论的是语言、数据结构与算法、操作系统原理、某种框架或中间件的原理与使用方式等这些“硬”性的东西，因为这些“硬”性的东西容易表述，里面的学问深浅也容易衡量。而软件建模、架构设计这种“软”性的东西，就不那么容易衡量了。大家都知道它们很重要，但又说不清楚里面到底包含了哪些学问，所以谈论这些东西通常都比较“虚”。最终就是大家很少在方法论方面谈论它们，而是等到项目中具体问题具体解决，这非常符合实用主义思维。另一方面，随着互联网的发展，很多大型网站或系统要处理海量的用户访问，需要解决高并发、高可用和由此带来的数据一致性问题，这也使得大家把大部分精力都用在了解决这些问题上面。我把这些问题称为“显性问题”，因为如果解决不好，会造成系统宕机，用户体验受损，给企业带来严重损失，大家都能意识到这种问题很重要。解决的思路通常有两个：第一，利用分布式系统的特性，不断地分拆，把大系统拆小，降低风险，各个击破：第二，小步快跑，快速迭代，设计不合理没关系，可以不断重构，不断发布新版本。但还有一类问题是“隐性问题”，是指系统的可重用性、可扩展性、可维护性等。因为一个系统由于设计得不好导致研发人力的投入和时间成本的增加，往往是没有办法显式地衡量的。可能不是系统设计得不好，而是业务本身就很复杂，又或者各部门之间的沟通协调问题，所以导致开发效率低。再说，即使系统设计得不好，做新功能有沉重的历史包袱，还能通过加班加点解决。但其实“隐性问题”比“显性问题”影响更大，因为它会让技术拖业务后腿，当有新需求的时候，系统无法跟随业务快速变化。本书不想偏废二者中的任意一个。因为对于一个系统来说，可能既面临高并发高可用的技术问题，又面临复杂的业务问题，如何很好地处理二者的关系，从而打通技术和业务的任督二脉，是本书想要探讨的。