精华内容
下载资源
问答
  • 大型网站架构之架构模式

    万次阅读 2020-05-22 13:14:53
    网站架构模式的目标:面临高并发访问,海量数据处理,高可靠运行等问题和挑战,我们在实践中提出很多解决方案,主要为了实现网站的高性能、高可用、易伸缩、可扩展、安全等架构目标。 网站架构模式具体方案 ...

    上节讲了大型网站的演变,今天讲下架构的模式,什么是模式呢?每一个模式描述了一个再我们周围不断重复发生的问题及问题解决方案的核心,这样你就能一次次重用该方案而不必去做重复的工作,可见模式的关键在于可重复性

     

    网站架构模式的目标:面临高并发访问,海量数据处理,高可靠运行等问题和挑战,我们在实践中提出很多解决方案,主要为了实现网站的高性能、高可用、易伸缩、可扩展、安全等架构目标。

     

    网站架构模式具体方案

     

    分层:分层是一种常见的架构模式,将系统在横向维度上切分为几个部分,每个部分负责单一的职责,然后通过上层对下层的依赖和调用完成整个系统工作。一般大型网站系统都分为下面3层:

    • 应用层:负责具体业务和视图展示;

    • 服务层:为应用层提供服务支持;

    • 数据层:提供数据存储访问服务;

    分层架构的挑战:必须合理规划层次边界和接口;

    分层架构的约束:禁止跨层次调用及逆向调用(数据层不允许调用服务层,服务层不允许调用应用层)

     

    分割分层是横向切分,分割则是纵向切分,将不同的功能和服务分割开,包装成高内聚低耦合的模块单元,这样做的好处在于:

    • 有助于软件开发和维护;

    • 便于不同模块的分布式部署,提高网站的并发处理能力和功能扩展能力;

     

    分布式:对于大型网站,分层和分割的目的都是为了便于分布式部署,将不同的模块部署在不同的服务器上,通过远程调用协同工作,分布式意味着我们可以使用更多的计算机完成同一个任务,计算机物理机越多,CPU,内存,存储资源就越多,能处理的并发访问和数据量也就更大,但是分布式也会带来一些问题:

    • 分布式服务意味着通过网络调用,会对性能造成影响;

    • 服务器越多,服务器宕机的概率就越大,使网站的可用性降低;

    • 数据在分布式环境下保持数据一致性也就比较困难;

    • 分布式下的事务也难以保证;

    • 分布式管理增了开发和维护的难度,切记不要为了分布式而分布式;

    分布式的常见几种方案:

    • 分布式应用和服务:将分层和分割后的应用和服务模块分布式部署,可以改善网站性能和并发性,加快开发和发布的速度,减少数据库连接资源消耗,使不同的应用复用共同的服务,便于业务扩展;

    • 分布式静态资源:网站的静态资源例如js,css,图片等资源独立分布式部署,并采用独立的域名,即动静分离;静态资源分布式部署可以减轻应用服务器的负载压力,通过域名独立加快浏览器并发加载的速度;

    • 分布式数据和存储:大型网站需要处理以P为单位的海量数据,单台计算机无法提供如此大的存储空间,这些数据需要分布式存储;

    • 分布式计算:目前网站普遍使用Hadoop和MapReduce分布式计算框架进行批处理计算,其特点就是移动计算而不是移动数据,将计算程序分发到数据所在的位置,以加速计算和分布式计算;

    • 分布式配置:网站线上服务器配置实时更新;

    • 分布式锁:分布式环境下实现并发和协同工作;

    • 分布式文件:支持云存储的分布式文件系统;

     

     

    集群:对于用户访问集中的模块,我们还需要考虑将其集群化,多台服务器部署相同应用构成一个集群,通过负载均衡器将请求分发给集群中不同的服务器处理。集群模式可以很好的扩展,当有更多用户访问时,只需要向集群中添加一台新的服务器加入集群即可,同时因为一个应用由多台服务器提供服务,当某台服务器发生故障时,负载均衡器或者系统的失效转移机制会将请求转发到集群中其他的服务器上,所以我们在配置集群时,至少需要2台以上服务器构成一个集群,目的就是为了提供系统的可用性

     

    :将数据存放在距离计算最近的位置,加快处理速度。大型网站架构设计一般在下面几个方面使用缓存设计:

    • CDN:即内容分发网络,部署在距离终端用户最近的网络服务商,用户网络请求总是先到达他的网络服务商那里,在这里缓存一些静态资源,就可以以最快的速度返回资源给用户;

    • 反向代理:属于网站前端部分,部署在网站的前端,当用户请求到达网站的时候,最先访问到的就是反向代理服务器,这里缓存网站的静态资源,无需将请求继续转发给应用服务器就能直接返回给用户;

    • 本地缓存:在应用服务器本地缓存一些热点数据(段时间内经常被访问的数据),应用程序可以在本机内存中直接访问数据,而无需访问数据库;

    • 分布式缓存:将数据缓存在一个专门的分布式缓存集群中,应用程序通过网络通信获取缓存的数据;

    使用缓存有2个前提条件:

    • 数据访问热点不均衡,某些数据会被更频繁的访问,这部分数据就该放入缓存;

    • 数据在某个时间段内有效,不会很快过期,否则缓存失效的数据就会因为失效而产生脏读,影响结果的正确性;

    使用缓存的优势:加快数据访问速度以及减轻后端应用和数据存储的负载压力;

     

    异步:大型网站的一个重要目标是降低软件的耦合性,系统解耦合的手段除了前面提到的分层、分割和分布式等,还有一个异步,业务之间的消息传递不是同步调用,而是将业务操作分成多个阶段,每个阶段之间通过共享数据的方式异步的进行协作;

    • 在单一服务器内部可以通过多线程共享内存队列的方式实现异步,业务前执行的线程将数据写入队列,后续线程从队列中读取数据进行处理;

    • 在分布式系统中,多个服务器集群通过分布式消息队列实现异步,分布式消息队列可以看做是内存队列的分布式部署;

    异步架构是典型的生产者和消费者模式,此外异步消息队列还有如下特性

    • 提高系统可用性:消费者服务器宕机时,数据会堆积在消息队列中,生产者服务器可以继续处理业务请求,不影响系统整体运行,当消费者服务器恢复正常后可以继续处理消息队列中的数据;

    • 加快网站响应速度:处在业务处理前端的生产者服务器在处理完业务请求后,可以将数据写入消息队列,不需要等待结果直接返回,减少响应延迟;

    • 消除并发访问高峰:使用消息队列将突发的高峰访问请求数据放入消息队列中,等待消费者依次处理,不会对整个网站负载造成太大的压力;

     

    冗余:网站需要24小时为用户提供服务,想要保证在服务器宕机的情况下,不影响网站的运行,不丢失数据,就需要将一定程度的服务器冗余运行,数据冗余备份,这样,当某台服务器宕机时,可以将其上面的服务和数据访问转移到其他冗余的服务器上。

    数据库除了定期备份,存档保存,实现冷备份之外,为了保证在线业务高可用,还需要对数据库进行主从分离,实时同步实现热备份。

    为了抵制一些非人为的天灾,一般还需要对整个网站数据中心进行备份,全球范围内部署灾备数据中心,网站程序和数据实时同步到多个灾备中心。

     

    自动化:主要包括自动化代码管理、自动化测试、自动化安全检测、自动化部署等实现发布过程自动化;此外还需要对服务器进行自动化监控、自动化报警、自动化失效转移(将失效的服务器从集群中隔离出去)、自动化失效恢复(重启服务之后同步数据保证数据的一致性)、自动化降级(通过拒绝部分请求及关闭一些不重要的服务将系统负载降至一个安全的水平)以及自动化分配资源(将空闲资源分配给重要的服务,扩大部署规模)。

     

    安全:主要从下面几点考虑

    • 通过密码手机校验码进行身份验证

    • 登录,交易等操作对网络通信进行加密

    • 防止机器人程序滥用网络资源攻击网站,使用验证码进行识别;

    • 对常见的XSS攻击、SQL注入进行编码转换等处理;

    • 对垃圾信息。敏感信息进行过滤

    • 对交易转账等重要操作根据交易模式和交易信息进行风险控制

     

     

    展开全文
  • 什么是软件架构模式 计划启动未开发的软件项目?然后选择正确的架构模式将对项目的结果起关键作用。选择市场上最流行或最新的技术并不总是意味着会带来最好的结果。但是,选择最合适的解决方案将为行之有效的问题和...

    什么是软件架构模式

    计划启动未开发的软件项目?然后选择正确的架构模式将对项目的结果起关键作用。选择市场上最流行或最新的技术并不总是意味着会带来最好的结果。但是,选择最合适的解决方案将为行之有效的问题和反复出现的问题提供可靠的解决方案。

    在软件工程领域,有一句著名的谚语说:“对您的简历做出决定”。这是什么意思?IT专业人员喜欢用最新,最先进的技术来装饰自己的简历,这将对他们的下一次面试有所帮助,但实际上对项目没有好处。例如,如果您的项目是为调查构建常规的数据捕获表单(不超过10个字段),并且少于100个用户只能使用一次,那么使用微服务等高度复杂的架构模式将是一场彻底的灾难。这就像建造一架战斗机只是为了逛街尽头的杂货店。

    选择架构模式时必须进行彻底的计划,并且必须考虑以下功能。

    成本

    上市时间

    用户数量(当前和将来)

    隔离级别(即:与其他系统/平台集成)

    如果我们开发没有任何架构模式的系统会怎样?最终将导致一个“大泥球”,每个阶层都与其他阶层相连。

     

    一个大泥球

    因此,只要您更改一个类的行为或结构,就会在其他多个类破裂的地方产生涟漪效应。您的软件是这样的吗?找出答案的最佳方法是使用软件设计逆向工程工具(如hex-ray)来分析您的组件/类结构。如果最终遇到上图所示的情况,那么就该重新考虑并对软件设计进行一些更改了。

    为了帮助您,我们将浏览主要软件架构模式的基础知识,以及每种模式的优缺点。然后,我们将详细说明哪种架构模式最适合给定场景。但是我们需要牢记一件事。在软件体系结构方面,没有黑白答案。不存在正确或错误的体系结构。它是非常主观的,并且取决于前面提到的多种因素。

     

    什么是软件架构模式?

    创建软件系统基本结构的原则称为软件体系结构。软件结构由软件元素及其相互关系组成,这些元素起着蓝图的作用,规划了要执行的任务的模式。软件设计团队极大地依赖于这些软件架构模式。应当指出,必须明智地选择软件体系结构,因为一旦实施,就不容易更改。

    软件架构模式很重要,因为它们是在架构设计中成功构建和测试的最佳解决方案的示例。有经验的开发人员会使用他们的知识和熟悉程度来包含这些模式,而不是在设计时人为或随机创建模式。此外,通过使用这些模式并突出显示它们,他们可以共享知识并教会新开发人员关键的设计策略。

    软件架构模式的好处

    模式有助于识别和指定抽象,这些抽象位于单个对象,类和组件的级别之上。单个应用程序本身很难解决一个复杂的问题。模式引入了具有多个应用程序组件的不同角色,从而有助于提供解决方案。他们定义了组成部分,以及他们在协作方式方面的职责和关系。

    此外,这些解决方案描绘了所介绍角色之间的关系。例如,观察者模式包括两个主要角色,即主题和观察者。这两个角色通过基于推送的更改传播机制进行协作,该机制确保组件可以保持彼此一致的状态。

    模式提供了一种通用语言和对设计概念的共同理解。即使某些算法,接口,实现和详细设计的重用并非总是可能的,这有助于简化架构知识和伪像的重用。例如,当开发人员了解Observer模式时,无需讨论如何管理其系统中一致的两个协作组件。

    模式有助于记录软件体系结构。通过对后果和实现折衷的深入评估,模式可以追踪选择特定设计选择而不是其他选择的原因。通过记录软件的意图,行为和结构,可以发现其中的模式,从而使软件开发路径,实践和维护变得更加顺畅。产品线架构使用有益的模式,因此开发人员应该意识到这一点。如果没有,他们将在不了解基本结构,机制和控制流程的情况下,难以正确使用它。基于模式的体系结构文档通过帮助开发人员专注于主要设计决策来帮助解决冲突。

    模式在具有明确定义的过程的软件构建中很有用。一些模式勾勒出特定的行为。这为满足特定领域中的应用程序的某些功能要求铺平了道路。例如,已记录了会计系统和公司财务以及提高响应系统容量的模式。

    模式还可以以一种形式来捕获经验,这种形式可以独立于特定的项目细节和约束,实现范例甚至通常是编程语言。在理解编码原则并解决新项目中的设计挑战时,开发人员可以实施容易出错,效率低下或无法维护的解决方案。模式可帮助开发人员选择合适的软件体系结构,而不会陷入域中的潜在陷阱。

    模式可以帮助来自不同编程语言文化的软件开发人员共享共同感兴趣的设计见解,同时还可以防止“语言大战”。在不同世代的开发人员之间进行知识转移有助于平衡并使各个社区的成员能够交流并重新关注特定语言社区的关注。尽管编码可能不同,但是可能会出现类似的模式,这些模式将支持新旧模式。

    体系结构模式不是编码准则

    必须注意,模式不能视为编码准则。可以将编码准则部分或从着重于代码样式的模式中放在一起。但是,事实并非如此。尽管有许多惯用的编码准则,但这不会自动使它们成为设计模式。例如,Sun Microsystem的JavaBeans规范一直将属性访问器的get和set前缀用作“设计模式”。但是,尽管这些前缀大多数都是模式,但即使在Java代码中,它们也无助于解决一般设计的设计问题。

    建筑图案的应用

    清楚地理解模式词汇总是很重要的,因为应用错误的模式会导致很多问题。有经验的开发人员将具有合理的判断力,这将有助于他理解在特定情况下何时不适合使用某种模式。如果应用不当,可能会导致不合适的设计和实现。

    对模式有浅浅的了解可以给开发人员一种印象,即他们可能精通该模式,即使有更好的解决方案。一个很好的例子是了解复杂模式(例如Proactor和Reflection)的结构和参与者。这些知识仅仅是一个方面,因此还不够。对于有效的模式应用,重要的是模式的本质必须反映在其上下文中,而不仅仅是结构中。

     

    原文:https://medium.com/@priyalwalpita

    展开全文
  • 架构设计(3)--架构模式

    万次阅读 2017-10-17 15:52:47
    模式的经典定义:每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该...在维基百科:架构模式是针对特定软件架构场景常见问题的通用、可重用解决方案。架构模式类似于软件设计模式,但范围更广。 ...

          

    架构设计学习思维导图: 架构设计系列主要的ADM(架构开发方法)主要基于TOGAF9或者TOGAF9.1来论述。这是个人学习实践和总结笔记,专注并不断积累和更新,努力精进自己。个人拙见,仅供参考。
    1、 架构概述:了解架构基础知识:架构定义、分类、级别、应用架构演进、架构是否合理、架构误区等。
         《谈谈架构》
    2、 原则模式:了解架构模式和设计原则。
         《架构设计原则》
          《架构模式》
    3、 瀑布模式:根据瀑布开发模式,从前期的架构愿景->到架构需求分析->架构设计
          《架构愿景分析》
          《架构需求分析》
          《如何设计一个架构》
    4、 架构三高:架构战术设计主要关注点:高可用、高性能、高效服务治理或者高并发
         《高可用架构设计》
         《高性能设计》
         《分布式服务治理》
    5、 具体知识点:架构实施知识点,框架、组件、限流、容错等知识。
         《分布式链路跟踪》
         《分布式链路跟踪:Zipkin实践》
         《分布式链路跟踪:skywalking实践》
         《我们自研log2跟踪组件》

    前言


            模式的经典定义:每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该问题的解决方案的核心,通过这种方式,我们可以无数次地重用那些已有的解决方案,无需再重复相同的工作。即模式是在特定环境中可以复用解决问题的一种方案 。

            什么是架构模式?在维基百科:架构模式是针对特定软件架构场景常见问题的通用、可重用解决方案。架构模式类似于软件设计模式,但范围更广。

            架构的本质是管理复杂性。如果你觉得架构不重要,可能是你做的事情不够复杂,或者是你没有管理好复杂性。架构模式虽多,经过抽象沉淀之后,也就那么几种,O'Reilly 出版过一本免费的小册子《Software Architecture Patterns》, 介绍了五种最常见的软件架构,是非常好的入门读物:

    1. 分层架构(比较传统的单体架构)

    2. 微服务架构(服务分割:当前比较流行的服务化架构,解决单体架构面临的问题,适合敏捷开发,快速迭代)

    3. 微核架构(又称插件架构,开发难度较高,一般用来做工具软件开发,如Eclipse,不太适合分布式业务场景)

    4. 事件驱动架构 (一般适用于应用局部场景,用来实现异步解耦)

    5. 云架构(现在的说法是云原生架构-Cloud Native,基于Docker、Kubernetes、Service Mesh 云原生架构)

     

    一、分层


    1、分层架构概念

    分层架构(layered architecture)是最常见的软件架构,也是事实上的标准架构。如果你不知道要用什么架构,那就用它。分层架构模式将软件分成若干个水平层,每一层都有清晰的角色和分工,不需要知道其他层的细节。层与层之间通过接口通信。

    分层:对模型中同一抽象层次上的包按横向进行划分的一种特定方式,将系统在横向维度上切分成几个部分,每个部分单一职责。通过分层,其作用:                           
    1、架构有规则的逻辑结构:从逻辑上将子系统划分成许多集合,而层间关系的形成要遵循一定的规则。                                          
    2、松散的耦合、易于维护:可以限制子系统间的依赖关系,使系统以更松散的方式耦合,从而更易于维护。

    层(layer)这个概念在计算机领域是非常NB的一个概念。计算机领域处处体现层的概念:计算机本身:(系统调用层、设备驱动层、操作系统层、CPU指令集,每个层都负责自己的职责。网络5层模型:(物理层、链路层、网络层、传输层、应用层)。

        层到了软件领域也一样好用。为什么呢?我们看看使用层技术有什么好处:

        ● 你使用层,但是不需要去了解层的实现细节。
        ● 可以使用另一种技术来改变基础的层,而不会影响上面的层的应用。
        ● 可以减少不同层之间的依赖。
        ● 容易制定出层标准。
        ● 底下的层可以用来建立顶上的层的多项服务。
        当然,层也有弱点:
        ● 层不可能封装所有的功能,一旦有功能变动,势必要波及所有的层。
        ● 效率降低。

    当然,层最难的一个问题还是各个层都有些什么,以及要承担何种责任。

    2、三层架构模式

    虽然没有明确约定,软件一定要分成多少层,网站一般分为三个层次:应用层服务层数据层,其具体结构如下图所示:

         

      通过分层,一个庞大系统切分成不同部分,便于分工合作和维护

            应用层:主要负责具体的业务逻辑处理

             服务层:提供可复用的服务

             数据层:负责数据的存储和访问

      但是,分层架构也有一些挑战:①必须合理规划层次边界和接口;②禁止跨层次的调用及逆向调用。

    4、常见的四层结构

    • 表现层(presentation):用户界面,负责视觉和用户互动
    • 业务层(business):实现业务逻辑
    • 持久层(persistence):提供数据,SQL 语句就放在这一层
    • 数据库(database) :保存数据

    有的软件在逻辑层(business)和持久层(persistence)之间,加了一个服务层(service),提供不同业务逻辑需要的一些通用接口。

    用户的请求将依次通过这四层的处理,不能跳过其中任何一层。

     

    5、分层架构模式的优缺点:

    优点

    • 结构简单,容易理解和开发
    • 不同技能的程序员可以分工,负责不同的层,天然适合大多数软件公司的组织架构
    • 每一层都可以独立测试,其他层的接口通过模拟解决

    缺点

    • 一旦环境变化,需要代码调整或增加功能时,通常比较麻烦和费时
    • 部署比较麻烦,即使只修改一个小地方,往往需要整个软件重新部署,不容易做持续发布(因为是单体架构)
    • 软件升级时,可能需要整个服务暂停
    • 扩展性差。用户请求大量增加时,必须依次扩展每一层,由于每一层内部是耦合的,扩展会很困难(单体架构,需求调整会贯穿每一层)

     

    二、微服务架构:分割和分布式


    1、微服务架构的背景

    随着业务深入,业务要求的产品功能越来越多,每个业务模块逻辑也都变得更加复杂,业务的深度和广度都增加,使得单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,增加新功能开发周期越来越长,维护成本越来越高。

    即当前单体架构无法满足当前业务发展需求的时候,就开始考虑拆分。

    2、微服务架构模式

    微服务架构(microservices architecture)是服务导向架构(service-oriented architecture,缩写 SOA)的升级。单体应用进行功能分割,形成分布式部署,服务之间互相解耦,通过远程通信协议(比如REST、SOAP)进行调用协调、互相配合,为用户提供最终价值。

    分层是横向逻辑分层,分割是分割是在纵向方面对软件进行切分,将不同的功能和服务分割开来包装成高内聚低耦合的模块单元,有助于软件开发和维护,还便于不同模块的分布式部署,提高网站的并发处理能力和功能扩展能力。

    现在开源的微服务框架比较多,如常用的有Spring Cloud、Dubbo、ServiceComb等等。

    3、微服务架构优缺点

    优点:

    1. 扩展性好:微服务形成高内聚低耦合的模块单元,各个服务之间低耦合,有助于软件开发和维护。
    2. 易于开发和维护: 微服务只关注特定的业务功能,所以它业务清晰、代码量较少。 开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的,所以整个应用也会被维持在一个可控状态。
    3. 容易部署: 单体应用只要有修改,就得重新部署整个应用,微服务解决了这样的问题。 一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。
    4. 技术栈不受限:在微服务架构中,可以结合项目业务及团队的特点,合理地选择技术栈。用最适合的技术方案去解决具体的问题,往往会事半功倍。例如某些服务可使用关系型数据库MySQL;某些微服务有图形计算的需求,可以使用Neo4j;甚至可根据需要,部分微服务使用Java开发,部分微服务使用Node.js开发。
    5. 方便测试:可以单独测试每一个服务。
    6. 故障隔离:一个服务出现问题不会影响整个应用,只影响自己;
    7. 按需伸缩提高并发能力:根据某个微服务性能瓶颈,可以实现细粒度的自由扩展,提高并发处理能力。

    微服务虽然有很多吸引人的地方,但是使用微服务架构也面临相应的挑战:

    1. 运维要求较高:由于强调互相独立和低耦合,服务可能会拆分得很细,这导致系统依赖大量的微服务,变得很凌乱和笨重。在单体架构中,只需要保证一个应用的正常运行。而在微服务中,需要保证几十甚至几百个服务服务的正常运行与协作,这给运维带来了很大的挑战。
    2. 分布式固有的复杂性:使用微服务构建的是分布式系统。对于一个分布式系统,考虑系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
    3. 接口调整成本高:微服务之间通过接口进行通信。如果修改某一个微服务的API,可能所有使用了该接口的微服务都需要做调整。
    4. 公共代码重复开发:很多服务可能都会使用到相同的功能,而这个功能并没有达到分解为一个微服务的程度,这个时候,可能各个服务都会开发这一功能(典型的例子就是一些通用的 Utility 类),从而导致代码重复。尽管可以使用共享库来解决这个问题(例如可以将这个功能封装成公共组件,需要该功能的微服务引用该组件),但共享库在多语言环境下就不一定行得通了。
    5. 分布式事务:分布式的本质使得这种架构很难实现原子性操作,交易回滚会比较困难,需要考虑CAP原理。

     

    4、单体应用如何拆分成微服务

    应用拆分首先明确拆分目的和需求,然后制定拆分原则。

    4.1 明确拆分的目的

    对于业务还没有理清楚、业务数据和处理能力还没有开始爆发式增长之前的创业公司,不需要考虑微服务架构模式,这时候最重要的是快速开发、快速部署、快速试错。

    1. 人员的角度:  多人维护一个工程,从开发开发、测试、部署、上线,效率是极低的。定位问题和修复问题非常困难。
    2. 业务的角度:代码已经严重影响到业务的效率,每个业务有各自的需求,需要给自己应用部署,各自开发需求。
    3. 从架构的角度:应用已经无法满足非功能性需求:无法满足并发需求、安全性、扩展维护很麻烦。需要梳理和抽取核心应用、公共应用,作为独立的服务下沉到核心和公共能力层,逐渐形成稳定的服务中心

         总之,系统拆分是单体程序向分布式系统演变的关键一步,也是很重要的一步,拆分的好坏直接关系到未来系统的扩展性、可维护性和可伸缩性等,拆分工作不难理解,但是如何正确拆分、有什么样的方法和原则能帮助我们拆分得到一个我们理想中的系统:高可用、可扩展、可维护、可伸缩的分布式系统。

    4.2、明确拆分需求

    1. 组织结构变化:从最初的一个团队逐渐成长并拆分为几个团队,团队按照业务线不同进行划分,为了减少各个业务系统和代码间的关联和耦合,几个团队不再可能共同向一个代码库中提交代码,必须对原有系统进行拆分,以减少团队间的干扰。
    2. 安全需求:这里所指的安全不是系统级别的安全,而是指代码或成果的安全,尤其是对于很多具有核心算法的系统,为了代码不被泄露,需要对相关系统进行模块化拆分,隔离核心功能,保护知识产权。
    3. 替换性:有些产品为了提供差异化的服务,需要产品具有可定制功能,根据用户的选择自由组合为一个完整的系统,比如一些模块,免费用户使用的功能与收费用户使用的功能肯定是不一样的,这就需要这些模块具有替换性,判断是免费用户还是收费用户使用不同的模块组装,这也需要对系统进行模块化拆分。
    4. 交付速度:单体程序最大的问题在于系统错综复杂,牵一发而动全身,也许一个小的改动就造成很多功能没办法正常工作,极大的降低了软件的交付速度,因为每次改动都需要大量的回归测试确保每个模块都能正确工作,因为我们不清楚改动会影响到什么,所以需要做大量重复工作,增加了测试成本。这时候就需要对系统进行拆分,理清各个功能间的关系并解耦。
    5. 技术需求:
    6. 1)、 扩展困难:单体程序由于技术栈固定,尤其的是比较庞大的系统,不能很方便的进行技术升级,或者说对引入新技术或框架等处于封闭状态;每种语言都有自己的特点,单体程序没有办法享受到其它语言带来的便利;对应到团队中,团队技术相对比较单一。
    7.  2)、 减少重复造轮子:相比于基于业务的垂直拆分,基于技术的横向拆分也很重要,使用数据访问层可以很好的隐藏对数据库的直接访问、减少数据库连接数、增加数据使用效率等;横向拆分可以极大的提高各个层级模块的重用性,减少重复造轮子。
    8. 6)、业务需求:由于业务上的某些特殊要求,比如对某个功能或模块的高可用性、高性能、可伸缩性等的要求,虽然也可以将单体整体部署到分布式环境中实现高可用、高性能等,但是从系统维护的角度来考虑,每次改动都要重新部署所有节点,显然会增加很多潜在的风险和不确定定性因素,所以有时候不得不选择将那些有特殊要求的功能从系统中抽取出来,独立部署和扩展。

     

    4.3.明确拆分原则

    4.3.1、业务原则

    1. 单一职责:1)、满足单一职责原则对于一个微服务而言,有限定的业务边界,可以帮助我们满足服务开发和交付的敏捷性;即每一个组件或者是模块应该只有一个职责或者是功能,功能要内聚。2)、高内聚、低耦合:拆分主要的参考因素就是最小化交互,高内聚、低耦合。错误的拆分边界,可能会导致功能之间的高耦合性和复杂性。3)、最小知识原则:一个组件或者是模块不应该知道其他组件或者模块的内部实现细节。
    2. 服务粒度适中:以业务模型拆分、有适当的边界。 1)、粗粒度优行原则:由服务提供方提供粗粒度的业务服务,封装数据及数据处理逻辑,屏蔽数据及业务规则,降低耦合度,提供更多业务价值;2)、适当边界:关注微服务的功能范围,一个服务的大小应该等于满足某个特定业务能力所需要的大小;
    3. 业务分层原则: 从整体规划上把业务分层,形成单向依赖,避免微服务之间的网状依赖关系;
    4. 可重用性拆分原则:将通用部分和专用部分分解为不同的应用。1) 若粗粒度服务不能满足重用需求,则拆分粗粒度服务,以增加重用;2)非唯一依赖:至少被2个以上其它微服务依赖的功能模块,才有必要独立成一个微服务。
    5. 稳定性原则:将稳定部分和易变部分分离。将动态部分和静态部分分解为不同的元素;将机制和策略分离为不同的元素;将应用和服务分离。

     

    4.3.2、技术原则

    1. 低耦合:可独立部署
    2. 轻量级的通信机制
    3. 性能要求拆分原则:若粗粒度服务性能达不到性能需求,则适当拆分服务,以满足性能需求;
    4. 安全性拆分原则:若粗粒度服务所包含的所有处理不在同一个安全级别上,为满足安全性需求拆分服务形成细粒度服务;

     

    4.3.3 其他治理原则

    1. 演进式拆分
    2. 考虑团队人员结构
    3. 避免环形依赖和双向依赖

    对于微服务组件拆分粒度应该是尽可能的拆小,但也不应该过分追求细粒度,要考虑适中不能过大或过小。按照单一职责原则和康威定律,在业务域、团队还有技术上平衡粒度。拆分后的代码应该是易控制,易维护的,业务职责也是明确单一的。

     

    三、插件架构:微核架构


    微核架构(microkernel architecture)又称为"插件架构"(plug-in architecture),指的是软件的内核相对较小,主要功能和业务逻辑都通过插件实现。

    内核(core)通常只包含系统运行的最小功能。插件则是互相独立的,插件之间的通信,应该减少到最低,避免出现互相依赖的问题。

     

    优点

    • 良好的功能延伸性(extensibility),需要什么功能,开发一个插件即可
    • 功能之间是隔离的,插件可以独立的加载和卸载,使得它比较容易部署,
    • 可定制性高,适应不同的开发需要
    • 可以渐进式地开发,逐步增加功能

    缺点

    • 扩展性(scalability)差,内核通常是一个独立单元,不容易做成分布式
    • 开发难度相对较高,因为涉及到插件与内核的通信,以及内部的插件登记机制

    微核架构的设计和开发难度较高,这就注定它在企业产品中用得不多,虽然它的优点还不少。

     

    四、事件驱动架构:异步


    事件(event)是状态发生变化时,软件发出的通知。

    事件驱动架构(event-driven architecture)就是通过事件进行通信的软件架构。它分成四个部分。

     

    事件驱动架构(event-driven architecture)核心组件:

    • 事件队列(event queue):接收事件的入口
    • 分发器(event mediator):将不同的事件分发到不同的业务逻辑单元
    • 事件通道(event channel):分发器与处理器之间的联系渠道
    • 事件处理器(event processor):实现业务逻辑,处理完成后会发出事件,触发下一步操作

    对于简单的项目,事件队列、分发器和事件通道,可以合为一体,整个软件就分成事件代理和事件处理器两部分。

    软件架构入门-分层架构、事件驱动、微服务架构和云原生架构

     

    事件驱动典型就是消息队列的生产者消费者模式,两者不存在直接调用,只要保持数据结构不变,彼此功能实现可以随意变化而不互相影响,这对网站扩展新功能非常便利。

    业务之间的消息传递不是同步调用,而是将一个业务操作分成多个阶段,每个阶段之间通过共享数据的方式异步执行进行协作。

    优点

    • 分布式的异步架构,事件处理器之间高度解耦,软件的扩展性好
    • 适用性广,各种类型的项目都可以用
    • 性能较好,因为事件的异步本质,软件不易产生堵塞
    • 事件处理器可以独立地加载和卸载,容易部署

    缺点

    • 涉及异步编程(要考虑远程通信、失去响应等情况),开发相对复杂
    • 难以支持原子性操作,因为事件通过会涉及多个处理器,很难回滚
    • 分布式和异步特性导致这个架构较难测试

    事件驱动架构在通信产品中应用得也非常广泛,典型的如状态机处理。事件驱动架构不适于做顶层架构,但适合做局部实现,几乎遍布在通信软件的各个角落。

     

    五、云原生架构-Cloud Native)


    1、理解云原生

    云架构(cloud architecture,现在的说法是云原生-Cloud Native)主要解决扩展性和并发的问题,是最容易扩展的架构。

    云原生从字面意思上来看可以分成云(云计算)原生(土著)两个部分。

        1)、首先从云的角度来理解

    云是和本地相对的,传统的应用必须跑在本地服务器上,现在流行的应用都跑在云端,云包含了IaaS,、PaaS和SaaS。

    云本质可以看作是一种提供稳定计算存储资源的对象,为了实现这点,像虚拟化、弹性扩展、高可用、高容错性、自恢复这些都是云的基本属性,云原生作为一种云计算,这是所具备的第一层含义。

        2)、第二层要从原生(Native ) 来看

    原生就是土生土长的意思,我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的,要充分利用云资源的优点,比如️云服务的弹性分布式优势。

     

    2、云原生的高扩展性

    云原生的高扩展性,主要原因是可以基于云上计算资源弹性伸缩。然后,业务处理能力封装成一个个处理单元(prcessing unit)。访问量增加,就新建处理单元(Docker容器);访问量减少,就关闭处理单元(Docker容器)。由于没有中央数据库,所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都独立分库。

    这个模式主要分成两部分:处理单元(processing unit)和虚拟中间件(virtualized middleware)。

    • 处理单元:实现业务逻辑(类似于微服务架构中的微服务)
    • 虚拟中间件:负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。

     

    虚拟中间件又包含四个组件:

    • 消息中间件(Messaging Grid):管理用户请求和session,当一个请求进来以后,决定分配给哪一个处理单元;
    • 数据中间件(Data Grid):将数据复制到每一个处理单元,即数据同步。保证某个处理单元都得到同样的数据;
    • 处理中间件(Processing Grid):可选,如果一个请求涉及不同类型的处理单元,该中间件负责协调处理单元;
    • 部署中间件(Deployment Manager):负责处理单元的启动和关闭,监控负载和响应时间,当负载增加,就新启动处理单元,负载减少,就关闭处理单元。

     

    3、云原生架构组成

    随着Docker、Kubernetes等容器化技术的快速发展,上述关于云架构描述有点陈旧了。当前最新的云原生架构,以Docker+Kubernetes为核心:

    微服务
    微服务解决的是我们软件开发中一直追求的低耦合+高内聚,比如某个系统的接口出了问题,结果影响了用户的前台操作,那“为啥这两个会互相影响?!”

    微服务可以解决这个问题,微服务的本质是把一块大饼分成若干块低耦合的小饼,比如一块小饼专门负责接收外部的数据,一块小饼专门负责响应前台的操作,小饼可以进一步拆分,比如负责接收外部数据的小饼可以继续分成多块负责接收不同类型数据的小饼,这样每个小饼出问题了,其它小饼还能正常对外提供服务。

    DevOps
    DevOps的意思就是开发和运维不再是分开的两个团队,而是你中有我,我中有你的一个团队。我们现在开发和运维已经是一个团队了,但是运维方面的知识和经验还需要持续提高。

    持续交付
    持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用,要做到这点非常非常难。我们现在每周一个版本,小布迭代前进。

    容器化
    容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了,每个服务都被无差别地封装在容器里,可以被无差别地管理和维护,现在比较流行的工具是docker和k8s。

    所以简单地把云原生理解为:云原生 = 微服务 + DevOps + 持续交付 + 容器化

     

    云原生架构图的主要特征:

    • 微服务应用运行支撑环境;
    • 以容器化应用的镜像作为交付标准;
    • 通过资源调度服务快速申请、释放资源;
    • 通过弹性伸缩快速扩展应用;
    • 状态监控;

     

    主要目标:

    1. 让开发人员聚焦业务逻辑的实现,其他交给容器云平台来完成;

    2. 支持业务系统的快速迭代,支撑业务的快速变化和发展;

    3. 构建以共享服务体系为核心的业务中台;

    比如某新零售企业设计的云原生架构图,以云和微服务架构为基础构建云原生应用,这里云可以是公有云、私有云、混合云等等。

     

    结束


    以上是从不同的视角,对架构进行了分类。实际应用中,各种架构并不是孤立的,可以根据业务环境和业务诉求,对各种架构进行综合和嫁接。每种架构都有其优点和缺点。优点不必多说,缺点则几乎都是通过工具工程(比如自动化发布工具、自动化测试等等)能力的方法来规避,工具工程对软件架构非常重要。

     

    展开全文
  • 架构模式 - 微内核模式

    千次阅读 2019-08-12 12:14:21
    微内核(Microkernel)架构模式结构如下图所示,有时也被称为插件架构模式(Plug-in Architecture Pattern),通过插件向核心应用添加额外的功能,可以实现功能的独立和分离。 微内核架构包含两部分组件,即内核...

    1. 微内核模式简介

    微内核(Microkernel)架构模式结构如下图所示,有时也被称为插件架构模式(Plug-in Architecture Pattern),通过插件向核心应用添加额外的功能,可以实现功能的独立和分离。

    微内核架构包含两部分组件,即内核系统(Core system)和插件(Plug-in Component)。微内核架构的内核系统通常提供系统运行所需的最小功能集,插件是独立的组件,包含特定的处理、额外的功能和自定义代码,用来向内核系统增强或扩展额外的业务能力。

    微内核是内核的一种精简形式。将通常与内核集成在一起的系统服务层被分离出来,变成可以根据需求加入选件  这样就可提供更好的可扩展性和更加有效的应用环境。使用微内核设计,对系统进行升级,显然只要用新模块替换旧模块,不需要改变整个系统架构。

    那么插件是什么?插件一般由以下几部分组成:插件暴露的接口(一般称为叫API),插件内部实现,插件扩展点以及插件配置。其中插件扩展点我们一般设计为SPI(Service Provider Interface,服务提供接口)。

    微内核模式的本质是管理插件以及协调插件之间的调用。插件插件本身是一个很大粒度的扩展点,可以整个被替换。同时插件可以提供自己的小粒度扩展点。这样整个系统就是由一个微内核加很多插件组成一个具备很强扩展性的系统。

    2. 微内核模式在Dubbo中的应用

    微内核架构风格在Dubbo中应用广泛,通信框架Mina、Netty和Grizzly,序列化方式Hession、JSON,传输协议Dubbo、RMI等都是这一架构风格的体现。我们可以通过简单的配置就能对这些具体实现进行排列组合构成丰富的运行时环境。       微内核架构风格提供的是一种解决扩展性问题的思路,Dubbo中实现这一思路的是SPI(Service Provider Interface)机制。

    JDK提供了服务实现查找的一个工具类java.util.ServiceLoader来实现SPI机制。当服务的提供者提供了服务接口的一种实现之后,在jar包的META-INF/services/目录同时创建一个以服务接口命名的文件,该文件里配置着实现该服务接口的具体实现类。而当外部程序装配这个模块的时候,就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名,并装载实例化,完成模块的注入。基于这样一个约定就能很好的找到服务接口的实现类,而不需要在代码里硬编码指定。Dubbo基于JDK中的SPI机制并做了优化,不会一次性实例化扩展点的所有实现并做了异常处理。

    Dubbo提供专门的@SPI注解,只有添加@SPI注解的接口类才会去查找扩展点实现,查找位置包括META-INF/dubbo/和META-INF/services/,而META-INF/dubbo/internal/中则定义了各项用于供Dubbo本身使用的内部扩展。举例来说,前面提到Dubbo对传输协议提供了Hessian、Dubbo等多种实现,Dubbo内部通过扩展点的配置确定使用何种机制。在dubbo-rpc-default工程和dubbo-rpc-hessian工程中,我们在META-INF/dubbo/internal/目录下都发现了com.alibaba.dubbo.rpc. Protocol配置文件,但里面的内容分别指向了com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol和com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol类,意味着当我们引用某个具体工程时,通过该工程中的配置项就可以找到相应的扩展点实现。dubbo-rpc-default工程的配置见下图。

    ExtensionLoader是实现扩展点加载的核心类,我们在上面例子的配置中确定了protocol的实现类,然后ExtensionLoader通过以下方式获取该类的实例:

    我们注意到ExtensionLoader有个getAdaptiveExtension方法,该方法的命名源于@Adaptive注解。ExtensionLoader注入的扩展点是一个Adaptive实例,直到扩展点方法执行时才决定调用哪一个扩展点实现。Dubbo使用URL对象传递配置信息,扩展点方法调用会根据URL参数中包含的Key-Value实现自适应,而URL的Key通过@Adaptive注解在接口方法上提供。如在下面的例子中,对于bind方法定义,Adaptive实现先查找"server" Key,如果该Key没有值则找“transport” Key值,从而决定加载哪个具体扩展点:

    而在Dubbo配置模块中,扩展点均有对应配置属性或标签,通过配置指定使用哪个扩展实现,如<dubbo:protocol name= "dubbo" />即代表应该获取dubbo协议扩展点,在调用过程中,Dubbo会在URL中自动加入相应的Key-Value对。

    对于Dubbo的整体架构,Microkernel作为一种架构风格只负责组装功能而所有功能通过扩展点实现。Dubbo自身功能也是基于这一机制实现,所有功能点都可被用户自定义扩展和替换。所有扩展点定义都通过传递携带配置信息的方式在运行时传入Dubbo,确保整个框架采用一致性数据模型。

     

    如果对文章感兴趣,可以关注我的微信公众号:程序员向架构师转型,或扫描下面的二维码。

    我出版了《系统架构设计:程序员向架构师转型之路》、《向技术管理者转型:软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍,并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》,欢迎交流。

    展开全文
  • 什么是架构模式和架构风格

    千次阅读 2018-10-16 09:29:19
    架构模式和架构风格有区别吗? 什么是架构模式? 什么是架构风格? 架构模式和架构风格的区别是什么? 有哪些架构模式? 有哪些架构风格? 架构模式=架构风格? 如果你搜索「架构模式和架构风格的区别」,你会发现...
  • 经典软件架构模式

    千次阅读 2020-08-30 22:20:26
    文章目录目录软件架构模式分层架构模式(Layered Architecture Pattern)基于事件的模式(Event-based Pattern)微内核模式(Microkernel Pattern)微服务模式(Microservices Pattern)基于空间的架构模式(Space-...
  • RabbitMQ集群架构模式-主备模式(Warren)--并发和数据量不高 RabbitMQ集群架构模式-远程模式(Shovel)--很少使用 RabbitMQ集群架构模式-多活模式(Federation)--异地数据复制的主流模式 RabbitMQ集群架构模式-...
  • 软件架构模式笔记

    千次阅读 2016-09-01 09:33:35
    本文内容整理自Mark Richards所著书籍《软件架构模式》(Software Architecture Patterns)。分层架构 模式特点 模式分析 事件驱动架构 中介Mediator拓扑结构 代理Broker拓扑结构 模式分析 补充 微内核架构 模式分析 ...
  • 可以将微内核架构模式识别为基于插件的模式。。也称为插件架构模式,它由两个主要组件组成,即核心系统和插件组件。 微内核架构模式的两个主要组成部分 核心系统包含运行系统所需的最少功能。在其他...
  • 摘要:一般地,架构模式大致可以分成两类,单体架构(monolithic architecture)和分布式架构(distributed architecture)。 前言 谈到软件系统设计的方法论,在代码层面,有我们熟悉的23种设计模式(design ...
  • 这次主要分享一下在架构设计过程中涉及的基础知识,主要是涵盖系统架构方法、架构模式及设计模式,便于大家在后续一起探讨HRMS系统的SaaS模式的架构设计。 一、设计模式  大家或多或少的都接触并在实际的开发过程...
  • 软件架构模式之分层架构

    万次阅读 多人点赞 2015-04-19 23:53:59
    对程序员来说很常见一种情况是在没有合理的程序架构时就开始编程,没有一个清晰的和定义好的架构的时候,大多数开发者和架构师通常会使用标准式的传统分层架构模式(也被称为多层架构)——通过将源码模块分割为几个...
  • 软件架构模式

    千次阅读 2017-10-11 21:58:57
    软件架构模式有: 管道——–过滤器模式,适用于批处理系统 面向对象模式—— 其典型应用是基于组件的软件开发 事件驱动模式—— 其典型的应用包括各种图形界面应用 分层模式——-如ISO/OSI的七层网络模型 C/S模式,...
  • 在做架构设计的时候,一般会采用一些架构模式,便于设计和以后需求变更时修改代码。如果设计模式选择得不正确那么很容易造成架构的混乱,代码也会变成怪物。 分层模式 分层模式 分层模式是最常见的模式。我们熟悉的...
  • 这是一个只多不少的统计,其中包括了很多通常认为是设计模式的模式,比如Bridge,Facade,Interpreter,Mediator等模式通常认为是设计模式,但是在许多情况下,也可以作为架构模式出现,因此也常常被当作架构模式。...
  • 业务逻辑架构模式

    2019-06-27 09:12:55
    业务逻辑架构模式(事务脚本,表模块,活动记录,领域模型)  其实各种架构模式并不是凭空出现的,是你写代码到达一定功底的时候自然出现的结果。走的弯路多了,就会主动去思考该如何将代码组织的更好,更...
  • 程序员必知的几种软件架构模式

    千次阅读 2020-10-27 14:11:45
    程序员必知的几种软件架构模式前序分层架构模式多层模式管道 - 过滤器架构客户端 - 服务器架构模型 - 视图 - 控制器架构(MVC)事件驱动架构微服务架构 前序 架构模式是对给定上下文的软件架构中常见问题的一种通用...
  • 大型网站架构之大型网站架构模式

    千次阅读 2019-10-07 20:57:17
    大型网站架构模式 什么是模式呢?(模式就是针对特定问题目前行业的解决方案) 模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。借助模式我们可以减少很多重复的工作。 大型互联网公司在实践...
  • 软件架构模式概述

    千次阅读 2016-09-17 12:15:20
    软件架构模式概述
  • 架构风格和架构模式速览

    千次阅读 2016-09-01 12:53:27
    除了这些风格,还有很多架构模式,比如插件、点对点、发布-订阅。有些作者对架构风格、模式和隐喻进行了区分。什么是架构风格呢?根据应用架构指南所说,架构风格指:一组原则。你可以把它看成是一组为系统家族提供...
  • 架构模式之MVVM

    千次阅读 2018-11-06 23:56:41
    架构模式之MVVM 前言 MVVM是一种架构模式,本文会涉及一小点vue代码,以及一篇简单的springboot的代码,建议在阅读本文档前先对这两门技术做一些学习。 什么是MVVM MVVM是三个单词的简称,分别是Model,View和...
  • 微服务架构模式语言包含了许多组模式。模式语言的值超出了它的各个模式的总和,因为它定义了模式之间的这些关系: Predecessor - Predecessor模式是一种激励自身模式需求的模式。例如,微服务架构模式是除了单体...
  • 1.架构模式   一个架构模式描述软件系统 里的基本的结构组织或纲要.架构模式提供一些事先定义好的子系统,指定他们的责任,并给出把他们组织在一起的法则和指南. 2.设计模式   一个设计模式提供一种提炼子系统或软件...
  • 网站架构模式

    万次阅读 2015-10-09 17:26:29
    网站架构模式为了解决高并发访问,海量数据,高可靠运行,提出了很多解决方案实现高性能,高可用,易伸缩,可扩展,安全等技术架构。分层横向分成, mvc, 视图,业务,数据库层 进制跨层调用 会给以后的优化带来很...
  • 五大主流软件架构模式

    千次阅读 2020-06-23 13:52:41
    首先,什么是软件架构模式? 架构模式是那些由软件架构师通过持续实践,进而总结出的、过往已验证的、优秀设计架构。它们往往能够被重复地使用到其他项目或领域之中。更具体地说,架构模式是需要在实践中反复发掘的...
  • MVC架构模式详细说明

    2020-07-15 10:10:33
     架构模式是一个通用的、可重用的解决方案,用于在给定上下文中的软件体系结构中经常出现的问题。架构模式与软件设计模式类似,但具有更广泛的范围。  模型-视图-控制器模式,也称为MVC模式(Model View ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 70,689
精华内容 28,275
关键字:

架构模式