架构设计（1）- 谈谈架构

1、什么是架构和架构本质

     在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。   此君说的架构和彼君理解的架构未必是一回事。

     我们主要针对互联网服server系统（类似网站）来定义架构：架构是系统的骨架，支撑和链接各个部分，包括组件、连接件、约束规范，以及指导这些内容设计与演化的原理。

     组件：类似应用服务，独立模块、数据库、nginx等等）、
     连接件：分布式调用、进程间调用、调用使用http协议还是tcp协议、组件之间的交互关系、
     约束规范：    设计原则、编码规范等等。
     

    即架构=组件+交互。

    这类似建筑设计规划，城市总体规划等，其实就是架构，只是应用的场景不同。

    架构的本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。

那什么样的系统要考虑做架构设计?

    1. 需求相对复杂.

     2. 非功能性需求在整个系统占据重要位置.

     3. 系统生命周期长,有扩展性需求.

     4.系统基于组件或者集成的需要.

     5.业务流程再造的需要.

2、架构分类

     架构可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构,.

     

      业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。

      熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。

      如何针对当前需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。

一、业务架构（俯视架构）：

      包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。

      看看京东业务架构（网上分享图）：

       

     

二、应用架构（剖面架构，也叫逻辑架构图）：

硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。

类似：

应用架构：应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。

应用架构图关键有2点：

1、职责划分:   明确应用（各个逻辑模块或者子系统）边界
   1）逻辑分层
   2）子系统、模块定义。
   3）关键类。
2、职责之间的协作：
   1）接口协议：应用对外输出的接口。
   2）协作关系：应用之间的调用关系。

    应用分层有两种方式：

    一种是水平分（横向），按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。

    另一种是垂直分（纵向），按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。

     应用的合反映应用之间如何协作，共同完成复杂的业务case，主要体现在应用之间的通讯机制和数据格式，通讯机制可以是同步调用/异步消息/共享DB访问等，数据格式可以是文本/XML/JSON/二进制等。

     应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。

     应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。

     系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。

三、代码架构（也叫开发架构）：

子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。

代码架构主要定义：

一、代码单元:
        1、配置设计
2、框架、类库。
二、代码单元组织：
    1、编码规范，编码的惯例。
2、项目模块划分
3、顶层文件结构设计，比如mvc设计。
4、依赖关系

四、技术架构，也可以叫系统架构

     技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。

     技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

　  系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。

    

五、部署拓扑架构图（实际物理架构图）：

      拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础。这个图主要是运维工程师主要关注的对象。

3、应用架构

    架构演进路程：

   ->初始阶段：LAMP,部署在一台服务器

   ->应用服务器和数据服务器分离

   ->使用缓存改善性能

   ->使用集群改善并发

   ->数据库地读写分离

   ->使用反向代理和cdn加速

   ->使用分布式文件和分布式数据库

   ->业务拆分

   ->分布式服务

    

     业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。

      企业一开始业务比较简单，比如进销存，此时面向内部用户，提供简单的信息管理系统（MIS），支持数据增删改查即可，单体应用可以满足要求。

      随着业务深入，进销存每块业务都变复杂，同时新增客户关系管理，以更好支持营销，业务的深度和广度都增加，这时需要对系统按照业务拆分，变成一个分布式系统。

     更进一步，企业转向互联网+战略，拓展在线交易，线上系统和内部系统业务类似，没必要重做一套，此时把内部系统的逻辑做服务化改造，同时供线上线下系统使用，变成一个简单的SOA架构。

      紧接着业务模式越来越复杂，订单、商品、库存、价格每块玩法都很深入，比如价格区分会员等级，访问渠道（无线还是PC），销售方式（团购还是普通）等，还有大量的价格促销，这些规则很复杂，容易相互冲突，需要把分散到各个业务的价格逻辑进行统一管理，以基础价格服务的方式透明地提供给上层应用，变成一个微内核的SOA架构。

      同时不管是企业内部用户，还是外部顾客所需要的功能，都由很多细分的应用提供支持，需要提供portal，集成相关应用，为不同用户提供统一视图，顶层变成一个AOA的架构（application orientated architecture）。

4、架构知识体系

架构演进

• 初始阶段：LAMP,部署在一台服务器
• 应用服务器和数据服务器分离
• 使用缓存改善性能
• 使用集群改善并发
• 数据库地读写分离
• 使用反向代理和cdn加速
• 使用分布式文件和分布式数据库
• 业务拆分
• 分布式服务

架构模式

• 分层：横向分层：应用层，服务层，数据层
• 分割：纵向分割：拆分功能和服务
• 分布式
  • 分布式应用和服务
  • 分布式静态资源
  • 分布式数据和存储
  • 分布式计算
• 集群：提高并发和可用性
• 缓存：优化系统性能
  • cdn
  • 方向代理访问资源
  • 本地缓存
  • 分布式缓存
• 异步：降低系统的耦合性 
  • 提供系统的可用性
  • 加快响应速度
• 冗余：冷备和热备，保证系统的可用性
• 自动化：发布，测试，部署，监控，报警，失效转移，故障恢复
• 安全：

架构核心要素

• 高性能：网站的灵魂
  • 性能测试
  • 前端优化
  • 应用优化
  • 数据库优化
• 可用性：保证服务器不宕机，一般通过冗余部署备份服务器来完成
  • 负载均衡
  • 数据备份
  • 自动发布
  • 灰度发布
  • 监控报警
• 伸缩性：建集群，是否快速应对大规模增长的流量，容易添加新的机器
  • 集群
  • 负载均衡
  • 缓存负载均衡
• 可扩展性：主要关注功能需求，应对业务的扩展，快速响应业务的变化。是否做法开闭原则，系统耦合依赖
  • 分布式消息
  • 服务化
• 安全性：网站的各种攻击，各种漏洞是否堵住，架构是否可以做到限流作用，防止ddos攻击。
  • xss攻击
  • sql注入
  • csr攻击
  • web防火墙漏洞
  • 安全漏洞
  • ssl

5、架构书籍推荐

 1. 《大型网站技术架构：核心原理与案例分析》

这是比较早，比较系统介绍大型网站技术架构的书，通俗易懂又充满智慧，即便你之前完全没接触过网站开发，通读前几章，也能快速获取到常见的网站技术架构及其应用场景。非常赞。

 2. 《亿级流量网站架构核心技术》

相比《大型网站技术架构》的高屋建瓴，开涛的这本《亿级流量网站架构核心技术》则落实到细节，网站架构中常见的各种技术，比如缓存、队列、线程池、代理……，统统都讲到了，而且配有核心代码。甚至连 Nginx 的配置都有！

如果你想在实现大流量网站时找参考技术和代码，这本书最合适啦。

3. 《架构即未来》

这是一本“神书”啦，超越具体技术层面，着重剖析架构问题的根源，帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。

4. 《分布式服务架构：原理、设计与实战》

这本书全面介绍了分布式服务架构的原理与设计，并结合作者在实施微服务架构过程中的实践经验，总结了保障线上服务健康、可靠的最佳方案，是一本架构级、实战型的重量级著作。

5. 《聊聊架构》

这算是架构方面的一本神书了，从架构的原初谈起，从业务的拆分谈起，谈到架构的目的，架构师的角色，架构师如何将架构落地……强烈推荐。

不过，对于没有架构实践经验的小伙伴来讲，可能会觉得这本书比较虚，概念多，实战少。但如果你有过一两个项目的架构经验，就会深深认同书中追本溯源探讨的架构理念。

6. 《软件架构师的12项修炼》

大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到，缺乏的知识可以通过决定改变的努力来弥补。

总结参考：

《大型网站技术架构》、《软件架构师设计》

http://www.rowkey.me/blog/2017/08/24/arch/

https://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650992472&idx=1&sn=ab1234fff936fda3e5cf1f6780cb733d&mpshare=1&scene=23&srcid=1017To1tEophZ2h3McPAESCO##

总结参考：

《大型网站技术架构》

转载自：https://blog.csdn.net/hguisu/article/details/78258430