架构浅谈

    做了这么久的程序员，多多少少也做过一些架构，今天得空，也谈谈工作6年的我对架构的一些了解。

1、什么是架构

    首先要搞明白什么是架构，窃以为架构是为了解决特定问题而规划的解决方案以及实施框架。这么说有点抽象，不妨拿盖房子来做个比较：

盖房子：

• 解决问题：住
• 解决方案：盖一栋房子，具体盖多大，盖多高，设施如何
• 实施框架：蓝图，给出房子的具体建设参数和建设规划

做架构：

• 解决问题：各种问题
• 解决方案：根据问题的具体范围，规划系统边界，预留系统弹性等
• 实施框架：包括但不限于，部署逻辑图，架构设计图，数据库设计图，等等，总之就是给系统画个蓝图

    结论：架构，就是为了解决某个问题（可大可小），产生的一套解决方案和实施框架的集合。

2、架构的大小

     架构是有大小的，架构的大小又是由针对的对象或者解决问题的大小决定的。

     当针对的是公司，你需要设计物理架构和逻辑架构，包括服务器的数量，性能，成本，系统的划分和数据交互方式，你不会去考虑系统内类的设计，除非你闲的蛋疼。各种架构设计图，系统间关系图，部署逻辑图是主要产出。

     当针对的是一个系统，你需要设计模块划分，模块间交互方式，类间关系，各种uml图将是最好的说明文档。

     当针对的是一个模块或者需求，你需要设计的就是应用架构了，比如这个类放这里是不是合适，这个组件是不是应该单独拆出来。这时候代码就是产出了。

     大的架构设计和小的架构设计关注点和产出物都不太一样，小架构设计可以遵循规范，想来也简单。大的架构设计没有规范，最考验功力，如何在灵活性和可维护性上做平衡，如何在成本和性能上做取舍，都是架构师的能力体现。大架构是解决抽象的大问题，小架构是解决具体的小问题。

     在开发活动中，无论大小，都会被架构包裹，无论是被大架构框住，还是在设计自己的小架构。

3、我在架构中

    我见过很多同学，认为我就是个写代码的，架构离我很遥远。其实不然，小到做需求，大到做项目、系统，都有架构设计的影子，应该把握各种机会，无论是做应用架构设计还是做大的架构，都是对解决问题的方案的设计，都是对自己的提高。虽然工作中的不同的角色，我们总是或多或少的和架构打交道。即使最小的开发者，开发最小的需求，也会有自己心里的路径或者规划，这也是架构的一部分。

所以，不要放弃自己，随时提高自己，想想这是不是最优的架构，才是重要的。总之，关于架构的想法挺多，这里真的只是浅谈。