经过这段时间的反思和整理，终于对架构有了一个较为明确的理解。架构是产品从无到有以及慢慢壮大过程中所需要的全部技术体系总称，架构过程：
- 配置、编码、测试、运维、监控分析、安全、运营等一系列技术体系的选型、取舍
- 技术选型基础上进行规划、设计、实现、迭代、制定相关规范
- 相关技术及规范运用到产品开发的整个过程中，并在产品迭代过程中对架构进行迭代优化
架构不止包含技术的框架，比如有人用了spring就觉得我已经是架构师了，其实架构并不是这么简单。我们以做一个新浪微博类似产品为例，现实应该是这样的：
- 产品初期，经典的LAMP快速开发实现第一个版本，功能也无比简单就是加好友，发消息，开发人员也只有一个小的队伍。此时的架构就体现为纯的技术选型及实现，包含了
- 配置：代码通过git管理，暂时无其他
- 编码：技术选型为LAMP，基于LAMP的开发框架封装，并在开发团队内制定开发规范
- 测试：技术人员手工测试
- 运维：手工发布，主备2台，mysql也做主备
- 监控：暂不需要
- 安全：发帖过滤、屏蔽
- 运营：后台删帖
- 随着用户的暴增以及功能的增加，产品需要迭代，架构也需要迭代。产品功能增强，性能需要优化，开发人员的增加，此时架构就发生了一个较大的变革：
- 配置：代码通过git管理，要分为多个模块，不同团队开发不同模块
- 编码：技术选型增加缓存、消息队列、搜索引擎等，框架封装更加复杂，抽象出基础层和服务层。分团队进行代码的维护，制定不同模块之间通信标准。推拉模型也提炼出来。
- 测试：单元测试+自动化测试
- 运维：批量自动化发布、回滚、支持灰度发布
- 监控：增加流量监控，机器监控
- 安全：发帖过滤、屏蔽，防范其他攻击
- 运营：后台删帖、大V管理等等
- 用户和流量再次增加后，产品再次发生变革，架构也再次变革。
- 配置：代码通过git管理，服务化，每个服务单独一个模块，不同团队开发不同模块
- 编码：技术选型需要考虑异地容灾，层次继续抽取，服务粒度细化，增加开放api，改进推送架构。
- 测试：单元测试+自动化测试
- 运维：批量自动化发布、回滚、支持灰度发布，异地数据同步
- 监控：增加流量监控，机器监控，增加缓存等监控
- 安全：发帖过滤、屏蔽，防范其他攻击，开放api权限管理oauth2，防止恶意调用
- 运营：后台删帖、大V管理等等
从上面的例子可以看出，架构是跟随产品进行迭代的，而且随着产品的越来越复杂，不可避免的需要不断拆分，多团队合作，运维自动化。架构也变成团队的工作，而不是一个架构师就搞定一切了。
阿里发展到现在架构也有些类似，有很多不同团队负责底层设施（中间件）的开发迭代及其架构的革新。业务也有不同的团队负责开发不同的业务模块，这个都使用统一的架构体系。技术保障部门维护统一的自动化运维工具，安全部门维护安全工具。不同部门都有自己的架构师，负责本部分的架构，不过比较遗憾的是没有一个总架构师的角度去推动总体架构演进及各个部门架构的优化。
