架构设计(1)-谈谈架构

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

    无架构,不系统,架构是大型系统的关键。从形上看,架构是系统的骨架,支撑和链接各个部分;从神上看,架构是系统的灵魂,深刻体现业务本质。

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

     架构的本质就是符合当前业务的发展并可以快速扩展。

2、架构分类

     架构可细分为业务架构、应用架构、技术架构。

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

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

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

扫描二维码关注公众号,回复: 24636 查看本文章

业务架构(俯视架构):

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

应用架构(剖面架构):

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

应用架构本质:

     应用作为独立可部署的单元,为系统划分了明确的边界,深刻影响系统功能组织、代码开发、部署和运维等各方面,应用架构定义系统有哪些应用、以及应用之间如何分工和合作。

    分有两种方式,一种是水平分,按照功能处理顺序划分应用,比如把系统分为web前端/中间服务/后台任务,这是面向业务深度的划分。另一种是垂直分,按照不同的业务类型划分应用,比如进销存系统可以划分为三个独立的应用,这是面向业务广度的划分。

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

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

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

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

 

技术架构:

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

    

3、应用架构演进

    架构演进路程:

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

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

   ->使用缓存改善性能

   ->使用集群改善并发

   ->数据库地读写分离

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

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

   ->业务拆分

   ->分布式服务

    

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

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

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

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

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

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

 

4、架构知识体系

 

  • 架构演进
    • 初始阶段:LAMP,部署在一台服务器
    • 应用服务器和数据服务器分离
    • 使用缓存改善性能
    • 使用集群改善并发
    • 数据库地读写分离
    • 使用反向代理和cdn加速
    • 使用分布式文件和分布式数据库
    • 业务拆分
    • 分布式服务
  • 架构模式
    • 分层:横向分层:应用层,服务层,数据层
    • 分割:纵向分割:拆分功能和服务
    • 分布式
      • 分布式应用和服务
      • 分布式静态资源
      • 分布式数据和存储
      • 分布式计算
    • 集群:提高并发和可用性
    • 缓存:优化系统性能
      • cdn
      • 方向代理访问资源
      • 本地缓存
      • 分布式缓存
    • 异步:降低系统的耦合性 
      • 提供系统的可用性
      • 加快响应速度
    • 冗余:冷备和热备,保证系统的可用性
    • 自动化:发布,测试,部署,监控,报警,失效转移,故障恢复
    • 安全:
  • 架构核心要素
    • 高性能:网站的灵魂
      • 性能测试
      • 前端优化
      • 应用优化
      • 数据库优化
    • 可用性:保证服务器不宕机,一般通过冗余部署备份服务器来完成
      • 负载均衡
      • 数据备份
      • 自动发布
      • 灰度发布
      • 监控报警
    • 伸缩性:建集群,是否快速应对大规模增长的流量,容易添加新的机器
      • 集群
      • 负载均衡
      • 缓存负载均衡
    • 可扩展性:主要关注功能需求,应对业务的扩展,快速响应业务的变化。是否做法开闭原则,系统耦合依赖
      • 分布式消息
      • 服务化
    • 安全性:网站的各种攻击,各种漏洞是否堵住,架构是否可以做到限流作用,防止ddos攻击。
      • xss攻击
      • sql注入
      • csr攻击
      • web防火墙漏洞
      • 安全漏洞
      • ssl

总结参考:

《大型网站技术架构》

猜你喜欢

转载自www.cnblogs.com/javalyy/p/8856296.html