yue_xin_tech

我们先来看看“架构”的含义：架构是软件整体结构与组件的抽象描述，它定义了系统涉及到的各个元素，并将这些元素通过一定的规则联合起来，协同完成整体的目标功能。而这一过程的产物就是所谓的架构图，它将涉及的元素和关系可视化出来，形成有标注、有说明的构建蓝图。实际上，架构它将需要面向多种人群进行阐述，比如 boss 想要了解的是概念，产品经理想看到的是设计，而开发工程师关心的则是能力边界。因此，我们往往会自顶向下的考虑软件的体系结构。从概念、模块、运行、代码的角度去组织。...

一、怎么理解架构？假如给你一个项目开发，你会怎么开始它？对于这个问题，我想很多猿友们都应该经历过吧。很多时候，我们会直接开干，让自己快速的进入 coding 状态。然而一旦遇上稍微有点规模，比如涉及到多个业务功能的开发，那大概率会在开发过程中经常的怀疑自己，甚至产生推倒重来的想法；又或者眼看就要交付了，只能将错就错，修修补补。最后，一个让人揪心的系统又诞生了。说到底，还是太草率了，如果我们能提前对项目进行梳理，将涉及到的产品形态、业务功能、技术方案不断的进行提炼总结，那还会这样吗？这也是为什么我们需

前言架构设计是一个技术活，它不仅考验着我们对整体的抽象整合能力，也检验了我们对业务的变化应对能力。一个好的架构，能让系统的依赖关系清晰明了，也能让后续的维护成本降到最低。那到底什么才是好的架构呢？个人觉得，站在使用者的角度，好的架构应该是易于理解的、高度自治的、可衡量的；站在实施效果的角度，应该是高可用、高并发、可扩展的。易于理解我们知道，之所以要进行架构设计，其主要目的在于降低系统的复杂度。在软件行业里，改需求加功能是家常便饭的事，几乎每隔半个月就有一次小的迭代。随着变动越来越多，系统将会越来越庞