初识架构

1.架构师，程序员的一条出路

   刚步入这一行时，冲劲十足，带着从底层搬砖开始做起的决心，数载后终于站稳了技术脚跟。但不久又开始迷茫，不谓前进方向。却是查看了百度词条对于“程序员”的释义让我豁然开朗，成为一名架构师！

   也许会有人看来我的发展方向来的太过随意，其实事情就是这么简单，不需要多么复杂而深刻的理由。

 

2.架构是什么

     想要成为一名架构师，需要对消息中间件、缓存工具、数据库等任何会用到的技术有自己深刻的理解，因为架构是充分考虑了项目的功能需求之后集成组件的一个实体。

     如果把架构用电脑来类比，那么由于主板型号的限制，可支持的内存条种类也不完全一样，另外硬件也在不断更新换代，软件运行需要占用的存储空间也越来越大。时代前进的步伐飞快，跟不上就会被抛弃。

     对于架构师，可以不去搭建一个实操环境来证明掌握了某个技术，但必须得知道它的基本概念与实现的优缺点。这样在需要你做出方案抉择的时候，才能够不会惊慌失措，毕竟那时候恐怕谁都帮不到你。

 

3.架构现学现用

     总体来说，我接触过的架构大都都是“web前端+spring框架后台+数据库”这种基本结构，流量大一点后可能会加入ehcache、redis缓存，随着访问量进一步增大，会考虑分库分表与集群问题，但是为避免因系统过于庞大耦合而复杂出现软件危机，需要尽量使用软件设计模式来缓解（为什么不能彻底解决呢？请查看软件危机的定义）这一状况，以下建议可供参考：

       ①梳理逻辑，重构代码

       ②集合零散项目可能方便管理维护，但增加了项目的复杂度，除非可以拆分为可以合并的小模块（缓存、日志等）

       ③加入的消息中间件等组件需要切实符合项目的需求，而不是“赶时髦”硬加上去

       ④在追求高性能时只对单个任务进行扩展

       ⑤在项目扩展时拆分出变化层与稳定层并设计它们之间的接口

     在架构设计的时候，需要注意以下原则与优先级

     1.合适：想要复制别人项目的成功需要有相应的人力、技术能力、资源积累

       最合适的才是最好的。如果说每一个可选的组件都可以列出一个关键属性优劣列表，那么综合考虑下，肯定有一个或者多个的组件最好用。这时候，不能临时加一个非关键属性来比较选出其中的一个组件作为最终方案，这时候，架构师的过往经验就能替他作出当前最合理的一个抉择。

     2.简单：每增加一个对象，复杂度便迭加当前对象数量

       在选择适合项目的组件过程中，可能会让项目变得更加不好维护并且复杂度增加，造成运维成本增加，而重构或者引人新技术可以保持项目结构的简单，避免无法维护的情况出现。

     3.演化：项目发展过程中不能避免的结构调优，是发展的本质

        随着时间推移，项目会越来越不能满足新的需求，需要及时的更新自己的“零部件”。可能不是修改代码逻辑的一点改动而已，也有可能是换用数据库，还有可能是大刀阔斧的架构切换。

     演化令项目逐渐复杂，这与简单原则冲突，而演化引人的新技术需要经过试错来验证，不一定会符合合适原则。若优先考虑演化，项目将变得越来越复杂，若不及时另外耗费大量人力去调整优化，或会达到无法维护的风险。

     而简单原则的优先级为什么在合适原则之后呢？若优先考虑简单原则，项目采用的技术可能会不合适，随着项目发展，或会使得采用技术的副作用影响逐渐变大，进而导致项目失败。