在开始这个系列之前，让我们来思考一个问题，什么是架构？当我们在谈到架构的时候，我们指的到底是什么？很多人都尝试给架构下一个定义，但是这些定义本身很难统一，结合我的理解，我认为架构的内涵包括以下内容：
- 最高层次的系统分解
- 系统中难以改变的东西
- 架构包括组成部分和这些组成之间的交互
架构是分层次的，不同层次的架构关注的内容不同，描述方法不同，实现方式也不同。按照TOGAF的定义，架构主要分为几个层次即业务架构、应用架构、数据架构和技术架构。
- 业务架构 - 关注组织（类如企业）的业务流程、业务域和业务组件
- 应用架构 - 业务架构中的流程和组件应该分成多少应用，应用之间如何集成和交互
- 数据架构 - 物理和逻辑数据的结构
- 技术架构 - 技术架构是应用架构的技术需求，包括如何进行纯技术层面的分层，开发框架选择，语言选择，涉及到各自非功能性需求的技术点（安全，性能，日志，异常，缓存，消息，大数据量）等需要使用的关键技术
关于架构层次的划分和相互之间的关系，可以参考http://blog.sina.com.cn/s/blog_493a84550101cfen.html。如果没有特别指明，文章包括后续的架构都指的是技术架构。
既然有了架构，就应该可以判断一个架构是好还是坏的，或者说哪方面好、哪方面坏；一个架构的衡量主要通过以下的系统特性来进行：
- 系统高可用性
- 系统性能（包括响应时间、吞吐量等）
- 系统伸缩性
- 系统可扩展性
- 系统安全性
我们要认识到，不同行业的架构复杂性有很大差别，例如电信行业的架构可能需要重点关注硬件设备，而企业应用一般来说业务逻辑复杂并且数据量大。在设计架构时，需要根据实际情况进行综合考虑，没有最好的架构，只有最合适的架构；架构的核心理念就是两个字“平衡”，根据业务需求找到多个系统特性之间的平衡点，它反映了业务、应用、技术甚至是组织架构间的博弈过程。