一、什么是架构和架构本质php
在软件行业，对于什么是架构，都有不少的争论，每一个人都有本身的理解。 此君说的架构和彼君理解的架构未必是一回事。前端
咱们主要针对互联网服server系统（相似网站）来定义架构：架构是系统的骨架，支撑和连接各个部分，包括组件、链接件、约束规范，以及指导这些内容设计与演化的原理。nginx
组件：相似应用服务，独立模块、数据库、nginx等等、web
链接件：分布式调用、进程间调用、调用使用http协议仍是tcp协议、组件之间的交互关系、sql
约束规范： 定规则作限制：例如设计原则、编码规范等等。数据库
是系统性地思考，权衡利弊以后在现有资源约束下的“最合理决策”，并由它来指导团队中的每一个人思想层面上的一致。编程
即架构=组件+交互。设计模式
这相似建筑设计规划，城市整体规划等，其实就是架构，只是应用的场景不一样。盖一座小房子，能够拍脑壳干起来，可是当你要盖一座大楼，若是没有一个建筑设计规划，能够想象搭理最后是什么样？缓存
架构的本质就是对系统进行有序化地重构以至符合当前业务的发展，并能够快速扩展。tomcat
那什么样的系统要考虑作架构设计?
1. 需求相对复杂.
2. 非功能性需求在整个系统占据重要位置.
3. 系统生命周期长,有扩展性需求.
4.系统基于组件或者集成的须要.
5.业务流程再造的须要.
二、架构分类
架构可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构,.
业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另外一方面影响技术选型。
熟悉业务，造成业务架构，根据业务架构，作出相应的应用架构，最后技术架构落地实施。
如何针对当前需求，选择合适的应用架构，如何面向将来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都须要深刻思考的问题。
1、业务架构（俯视架构）：
包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。
没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构每每会给系统带入大坑，任何不基于业务作异想天开的架构都是耍流氓。
全部问题的前提要搞清楚咱们今天面临的业务量有多大，增加走势是什么样，并且解决高并发的过程，必定是一个按部就班逐步的过程。 合理的架构可以提早预见业务发展1~2年为宜。这样能够付出较为合理的代价换来真正达到技术引领业务成长的效果。
2、应用架构（剖面架构，也叫逻辑架构图）：
硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。
相似：
应用架构：应用做为独立可部署的单元，为系统划分了明确的边界，深入影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合做。这里所谓应用就是各个逻辑模块或者子系统。
应用架构图关键有2点：
一、职责划分: 明确应用（各个逻辑模块或者子系统）边界
1）逻辑分层
2）子系统、模块定义。
3）关键类。
二、职责之间的协做：
1）接口协议：应用对外输出的接口。
2）协做关系：应用之间的调用关系。
应用分层有两种方式：
一种是水平分（横向），按照功能处理顺序划分应用，好比把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。
另外一种是垂直分（纵向），按照不一样的业务类型划分应用，好比进销存系统能够划分为三个独立的应用，这是面向业务广度的划分。
应用的合反映应用之间如何协做，共同完成复杂的业务case，主要体如今应用之间的通信机制和数据格式，通信机制能够是同步调用/异步消息/共享DB访问等，数据格式能够是文本/XML/JSON/二进制等。
应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分下降了业务复杂度，系统更有序，合增长了技术复杂度，系统更无序。
应用架构的本质是经过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。
系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特色；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。
3、代码架构（也叫开发架构）：
子系统代码架构主要为开发人员提供切实可行的指导，若是代码架构设计不足，就会形成影响全局的架构设计。好比公司内不一样的开发团队使用不一样的技术栈或者组件，结果公司总体架构设计就会失控。
代码架构主要定义：
1、代码单元:
一、配置设计
二、框架、类库。
2、代码单元组织：
一、编码规范，编码的惯例。
二、项目模块划分
三、顶层文件结构设计，好比mvc设计。
四、依赖关系
4、技术架构，也能够叫系统架构
技术架构：肯定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。
技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等作系统级的把握。
系统架构的设计要求架构师具有软件和硬件的功能和性能的过硬知识，这也是架构设计工做中最为困难的工做。
5、部署拓扑架构图（实际物理架构图）：
拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是全部架构的基础。这个图主要是运维工程师主要关注的对象。
三、应用架构
架构演进路程：
->初始阶段：LAMP,部署在一台服务器
->应用服务器和数据服务器分离
->使用缓存改善性能
->使用集群改善并发
->数据库地读写分离
->使用反向代理和cdn加速
->使用分布式文件和分布式数据库
->业务拆分
->分布式服务
业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构须要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。
企业一开始业务比较简单，好比进销存，此时面向内部用户，提供简单的信息管理系统（MIS），支持数据增删改查便可，单体应用能够知足要求。
随着业务深刻，进销存每块业务都变复杂，同时新增客户关系管理，以更好支持营销，业务的深度和广度都增长，这时须要对系统按照业务拆分，变成一个分布式系统。
更进一步，企业转向互联网+战略，拓展在线交易，线上系统和内部系统业务相似，不必重作一套，此时把内部系统的逻辑作服务化改造，同时供线上线下系统使用，变成一个简单的SOA架构。
紧接着业务模式愈来愈复杂，订单、商品、库存、价格每块玩法都很深刻，好比价格区分会员等级，访问渠道（无线仍是PC），销售方式（团购仍是普通）等，还有大量的价格促销，这些规则很复杂，容易相互冲突，须要把分散到各个业务的价格逻辑进行统一管理，以基础价格服务的方式透明地提供给上层应用，变成一个微内核的SOA架构。
同时无论是企业内部用户，仍是外部顾客所须要的功能，都由不少细分的应用提供支持，须要提供portal，集成相关应用，为不一样用户提供统一视图，顶层变成一个AOA的架构。
四、衡量架构的合理性
架构为业务服务，没有最优的架构，只有最合适的架构， 架构始终以高效，稳定，安全为目标来衡量其合理性。
1、稳定性。指标：
1. 高可用：要尽量的提升软件的可用性，我想每一个操做人都不肯意看到本身的工做没法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提升测试覆盖率等方式来一步一步推动。
2、高效指标：
1. 文档化：无论是总体仍是部分的整个生命周期内都必须作好文档化，变更的来源包括但不限于BUG，需求。
2. 可扩展：软件的设计秉承着低耦合的理念去作，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，而且支持在适时对架构作出重构。
3. 高复用：为了不重复劳动，为了下降成本，咱们但愿可以重用以前的代码、以前的设计。这点对于架构环境的依赖是最大的。
3、安全指标
1. 安全：组织的运做过程当中产生的数据都是具备商业价值的，保证数据的安全也是刻不容缓的一部分。以避免出现XX门之类丑闻。加密、https等为广泛手段
五、常见架构误区
误区1——架构专门由架构师来作，业务开发人员无需关注：架构的再好，最终仍是须要代码来落地，而且组织越大这个落地的难度越大。不仅仅是系统架构，每一个解决方案每一个项目也由本身的架构，如分层、设计模式等。若是每一块砖瓦不够坚固，那么整个系统仍是会由崩塌的风险。所谓“千里之堤，溃于蚁穴”。
误区2——架构师肯定了架构蓝图以后任务就结束了：架构不是“空中楼阁”，最终仍是要落地的，可是架构师彻底不去深刻到第一线怎么知道“地”在哪？怎么才能落的稳妥当当。
误区3——不作出完美的架构设计不开工：世上没有最好架构，只有最合适的架构。咱们须要的不是一会儿造出一辆汽车，而是从单轮车 --> 自行车 --> 摩托车，最后再到汽车。想象一下2年后才能造出的产品，当初市场还存在吗？
六、架构知识体系
架构演进
初始阶段：LAMP,部署在一台服务器
应用服务器和数据服务器分离
使用缓存改善性能
使用集群改善并发
数据库地读写分离
使用反向代理和cdn加速
使用分布式文件和分布式数据库
业务拆分
分布式服务
架构模式
分层：横向分层：应用层，服务层，数据层
分割：纵向分割：拆分功能和服务
分布式
分布式应用和服务
分布式静态资源
分布式数据和存储
分布式计算
集群：提升并发和可用性
缓存：优化系统性能
cdn
方向代理访问资源
本地缓存
分布式缓存
异步：下降系统的耦合性
提供系统的可用性
加快响应速度
冗余：冷备和热备，保证系统的可用性
自动化：发布，测试，部署，监控，报警，失效转移，故障恢复
安全：
架构核心要素
高性能：网站的灵魂
性能测试
前端优化
应用优化
数据库优化
可用性：保证服务器不宕机，通常经过冗余部署备份服务器来完成
负载均衡
数据备份
自动发布
灰度发布
监控报警
伸缩性：建集群，是否快速应对大规模增加的流量，容易添加新的机器
集群
负载均衡
缓存负载均衡
可扩展性：主要关注功能需求，应对业务的扩展，快速响应业务的变化。是否作法开闭原则，系统耦合依赖
分布式消息
服务化
安全性：网站的各类攻击，各类漏洞是否堵住，架构是否能够作到限流做用，防止ddos攻击。
xss攻击
sql注入
csr攻击
web防火墙漏洞
安全漏洞
ssl
七、架构书籍推荐
1. 《大型网站技术架构：核心原理与案例分析》
这是比较早，比较系统介绍大型网站技术架构的书，通俗易懂又充满智慧，即使你以前彻底没接触过网站开发，通读前几章，也能快速获取到常见的网站技术架构及其应用场景。很是赞。
2. 《亿级流量网站架构核心技术》
相比《大型网站技术架构》的高屋建瓴，开涛的这本《亿级流量网站架构核心技术》则落实到细节，网站架构中常见的各类技术，好比缓存、队列、线程池、代理……，通通都讲到了，并且配有核心代码。甚至连 Nginx 的配置都有！
若是你想在实现大流量网站时找参考技术和代码，这本书最合适啦。
3. 《架构即将来》
这是一本“神书”啦，超越具体技术层面，着重剖析架构问题的根源，帮助咱们弄清楚应该以何种方式管理、领导、组织和配置团队。
4. 《分布式服务架构：原理、设计与实战》
这本书全面介绍了分布式服务架构的原理与设计，并结合做者在实施微服务架构过程当中的实践经验，总结了保障线上服务健康、可靠的最佳方案，是一本架构级、实战型的重量级著做。
5. 《聊聊架构》
这算是架构方面的一本神书了，从架构的原初谈起，从业务的拆分谈起，谈到架构的目的，架构师的角色，架构师如何将架构落地……强烈推荐。
不过，对于没有架构实践经验的小伙伴来说，可能会以为这本书比较虚，概念多，实战少。但若是你有过一两个项目的架构经验，就会深深认同书中追本溯源探讨的架构理念。
6. 《软件架构师的12项修炼》
大多数时候所谓的“技术之玻璃天花板”其实只是缺少软技能而已。这些技能能够学到，缺少的知识能够经过决定改变的努力来弥补。