精华内容
参与话题
问答
  • Saas系统架构的思考,多租户Saas架构设计分析

    万次阅读 多人点赞 2019-06-14 13:39:35
    ToBSaas系统最近几年都很火。...最近一年,有幸架构一个Crm saas 系统,上线了几个月来,各方面都比满意。整个系统创建过程,踩了很多坑,收获也比较多。总结一下Saas系统架构一些特点: Saas系统分...

            ToB Saas系统最近几年都很火。很多创业公司都在尝试创建企业级别的应用 cRM, HR,销售, Desk Saas系统。很多Saas创业公司也拿了大额风投。毕竟Saas相对传统软件的优势非常明显。   

    最近一年,有幸架构一个Crm saas 系统,上线了几个月来,各方面都比满意。整个系统创建过程,踩了很多坑,收获也比较多。总结一下Saas系统架构一些特点:

    Saas系统分级

    SaaS系统架构成熟度模型的5个级别——从“混乱”到“乌托邦“

    第0级(混乱):每次新增一个客户,都会新增软件的一个实例。
    第1级(受控的混乱):所有客户都运行在软件的同一个版本上,而且任何的定制化都通过修改配置来实现。
    第2级(多租户[multi-tenant]、高层建筑[Highrise]):所有的客户都已经可以在软件的同一个版本上运行了,而且他们都在同一个“实例”上运行。
    第3级(多租户, 扩建[Build-Out]):此时你已经拥有了多租户、单一版本的软件模型。不过你还是可以通过硬件扩展(scale-out)的方式来进行扩充。
    第4级(乌托邦):如同第3级,除非你可以找出有效的方式,以在不同的“实例”上运行不同版本的软件

    应用程序必须支持多租户:

        多租户可以分为几个不同的类别(如列表下方的图所示):
        1.1,云中的简单虚拟化,其中只对硬件进行共享。
        1.2,共享应用程序,对每个租户使用不同的数据库。
        1.3,共享应用程序和数据库(效率最高,真正的多租户)。

    1.分层设计

    Saas系统分层大概是:

    Saas系统分层
    Saas系统分层

     

    Saas系统分层:租户识别>应用层>数据访问层>缓存层>数据库

    业务代码都是写在应用层。

    租户识别可以用spring拦截器实现,然后使用ThreadLocal传递给后端

    数据库和缓存层对应用层应该是透明的。程序员在写代码的时候,只关心业务逻辑,不应该担心多租户的问题。

     

    2.数据隔离要透明

    saas系统说起来很简单,任何系统似乎加个tenant_id(租户id)就变成saas系统了。比如原来的用户登录是:

    select username,password from users where email='abc@qq.com'

    改成

    select username,password from users where email='abc@qq.com' and tenant_id =1;

    对于复杂业务的saas系统,这样做法非常危险,而且开发效率很低。你想想如果那个程序员写sql时候忘了加 “ and tenant_id =1” . 结果不堪设想。

    比较好做法是在数据库访问层对SQL进行改写。

    TenantContext.exec("select username,password from users where email='abc@qq.com' ");

    在连接池根据TenatnContext改写Sql. 

    这样做好处是,一来程序猿最多把系统搞down了,也不至于信息串了互相泄露。二来将来做分表分库也很方便,上层应用不用修改。

    3. 租户识别方案

    比较好做法是通过url识别租户。系统是给租户生成一个随机的三级域名,比如 abc.crm.baidu.com.   如果客户想使用自己的域名,可以在cname到我们生成的三级域名,并在管理系统里面做绑定。

    这样一个租户可以有两个域名,访问saas,一个随机生成的三级域名,另外一个租户自己的域名.代码里面可以根据过来的域名,判断是那个租户然后初始化TenantContext.

    如果不想通过域名来做,也可以通过登录名来判断。这种方式要涉及到租户切换问题。

    4. 智能DNS

    以后补充。

    5. 租户管理系统(计费,订购,定制,充值,催缴)

    Saas系统是必须考虑计费系统和租户控制系统。这个系统需要都是独立设计。比如那个租户购买了那些模块,一个月多少钱。租户可以创建最多的用户数。计费到期邮件提醒等功能。

    计费方式一般有两种,周期性计费,类似月租方案,和使用量计费,用多少付多少。 周期性计费比较简单。也可以两者结合起来。

    6. 定制化开发

    SAAS的优势在于一套系统多人使用,似乎和定制化开发有冲突。比如A客户想要A功能,B客户不想要。但定制化开发是无法避免的,比如CRM系统这样复杂的系统,不可能一套系统满足所有公司的要求。定制化开发尽可能分系统,分模块去做。然后通过控制台中配置不同租户订购不同模块,那些模块可以在前端页面上显示。不同的子系统需要分开部署。前端可通过nginx根据url分发,比如 abc.crm.baidu.com/bi/xxx/xx这个地址,就分发到BI子系统。不要尝试OSGI去搞模块化,这个是个大坑。

    还有开发和产品,现有需求一定要分析清楚,不要一上线发现后患无穷。新功能尽量做的独立可以配置。

    7. 灰度升级

    SAAS付费企业客户对系统问题都特别敏感。 为了减少升级可能出现问题的影响范围,一般都采用灰度升级策略。如果使用了url来区分不同租户,灰度升级配置就会很方便。可以配置nginx 来根据域名做分发,比如租户A(aaa.com)到实例1(版本1.0),租户B(bbb.com)到实例2(版本). 当需要域名配置非常多的时候,nginx配置文档会乱。这块时候可以考虑使用nignx_lua来写一些扩展模块。

    8. 容量估计

     

    9. Saas平台架构分层分析

    Saas平台架构需要完成从用户申请链接saas到用户对自己购买的功能模块的应用整个过程,用户用起saas看似简单快捷,但这个过程却需要saas平台架构默默完成的非常复杂的处理过程。通过对saas平台架构的了解,可以清晰的分化数据的处理过程,让用户也可以明白saas平台架构处理数据的优势。下面介绍:saas平台架构分为哪几部分。

     

    saas平台架构之呈现层:

    saas平台架构的呈现层可以使用的客户端可能都浏览器或本地客户端。如果是浏览器则需要Web界面技术、交互技术等技术(如:HTMl5技术、CSS3技术、Ajax技术等)的支持,如果是软件客户端则需要远程桌面技术、软件交互技术等技术支持。

    saas平台架构之调度层:

    saas平台架构的调度层体现分布式系统的特性之一。调度层首先负责识别并通过AAA认证每个用户请求,然后根据业务处理器的负载、业务特征进行合理的调度。通过应用这样的架构SaaS平台可以横向扩展。此外在存储、缓存等方面为了满足平台的横向扩展需求,调度层也必须具有良好的可扩展性。

    saas平台架构之业务层:

    saas平台架构的业务层负责接收调度层转发过来的请求,而且还要通过对接受到的请求执行真正的业务逻辑。一般来说业务逻辑的执行使用一台服务器就够了。因此业务层实际是由一排对等的服务器组成的,每台服务器都执行相同的业务逻辑。

    saas平台架构之数据层:

    saas平台架构的数据库集群用于处理存储关系性很强并且对事务性要求很高的业务数据,这类数据目前还要用传统的数据库集群技术来解决,saas平台架构的数据库集群主要是根据业务特征制定数据拆分方案。同时分布式数据库用于存放海量但关系性不强的数据(如:用户的操作日志等)。

    以上是对“Saas系统架构的思考,多租户Saas架构设计分析”的介绍,从saas平台架构处理数据可以看出saas平台的应用有很强的优势,如用户使用saas非常方便简单只要浏览器或本地客户端接口,saas平台处理数据要经过层层认证saas产品安全可靠,saas平台优化处理数据提高saas性能。

    多租户Saas系统架构还应该满足以下需求:

    编号 需求 描述
    1 软件授权 云平台付费授权机制,可按时间、功能、数量等进行付费授权
    2 组织入驻 允许组织主动申请加入平台
    3 实名认证 个人实名认证、组织实名认证
    4 资质审核 个人和组织的资质审核,如对获得的证书或荣誉进行审核
    5 组织绑定 个人账户绑定组织,与组织建立关联关系
    6 组织解绑 个人账户与组织进行解绑
    7 账户注销 个人账户注销,并销毁所有个人资料和档案
    8 统一登录 即 SSO
    9 统一注册 提供统一的用户注册页面

    部分资料整理自:

    http://www.ruanally.com
    ​​​​​​​http://qk.gam7.com
    ​​​​​​​​​​​​​​http://www.ruanbe.com

     

    展开全文
  • 架构设计(1)-谈谈架构

    万次阅读 多人点赞 2017-10-17 11:18:15
    1、什么是架构架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概念是人认识这...

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

    一、架构是什么


          在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义, 因为概念是人认识这个世界的基础和用来沟通的手段,如果对架构概念理解不一样,那沟通起来自然不顺畅。

         Linux有架构,MySQL有架构,JVM也有架构,使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构,应该关注哪一个?想要清楚以上问题需要梳理几个有关系又相似的概念:系统与子系统、模块与组建、框架与架构:  

    一、系统与子系统

    系统:泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能独立完成的工作能力的群体。

    子系统:也是由一群关联的个体组成的系统,多半是在更大的系统中的一部分。

    二、模块与组件

    都是系统的组成部分,从不同角度拆分系统而已。模块是逻辑单元,组件是物理单元。

    模块就是从逻辑上将系统分解, 即分而治之, 将复杂问题简单化。模块的粒度可大可小, 可以是系统,几个子系统、某个服务,函数, 类,方法、 功能块等等。

    组件可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。

    三、框架与架构

    框架是组件实现的规范,例如:MVC、MVP、MVVM等,是提供基础功能的产品,例如开源框架:Ruby on Rails、Spring、Laravel、Django等,这是可以拿来直接使用或者在此基础上二次开发。

    框架是规范,架构是结构。

    在TOGAF9是这么定义:一个系统基本的构件(子系统, 模块, 组件),体现在它的各个构件、构件间的相互关系、构件与环境间的关系,以及对系统设计和演进进行治理的原则中。两种含义:
    (1)、一个系统的形式化描述,或指导系统实现的构件级的详细计划。
    (2)、一组构件的结构、构件间的相互关系、以及对这些构件的设计和随时间演进的过程进行治理的一些原则和指导策略

    我在这重新定义架构:软件架构指软件系统顶层结构设计。

    架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则.  并由它来指导团队中的每个人思想层面上的一致。

    涉及四方面:

    1、系统性思考的合理决策:比如技术选型、解决方案、成本评估、性价比评估等等。

    2、明确的系统骨架:明确系统有哪些部分组成。

    3、系统协作关系:各个组成部分如何协作来实现业务请求。

    4、约束规范和指导原则:保证系统有序,高效、稳定运行,包括规范、原则、流程等内容。

     

        

    二、架构设计目的


          如果没有架构设计,说明你的系统不够复杂。随着业务的增长,系统由单体应用渐进演化为分布式和微服务化。系统整体的复杂性越来越高,技术团队可能从一个团队变成多个专业化团队。假如没有架构设计,系统定会是一个无序失控的状态,带来的问题:

          1、应用服务的边界不是很清晰:到底该怎么拆分没有一个明确的原则,研发人员为了所谓微服务化而拆分,而不是从当前业务考虑。我们系统出现过类似的情况:一个简单项目拆分成8个子服务,问他为什么这么拆分,说微服务化是为了应对以后扩展方便。结果这个项目从2017年到现在都没有再修改过,接手人宁愿新开发一个项目也不愿重构。

          2、应用服务层次不清晰:导致服务依赖出现网状依赖结构。

          3、系统应用服务跟踪问题:由于微服务化后,服务出现问题后,你很难快速的定位问题。这是我们踩过不少坑,我们使用dubbo服务化,系统一旦出现问题,一推人手忙脚乱。

          4、系统服务监控问题:由于研发人员基本没有服务监控意识,都是出现问题后再想办法如何添加服务监控接口。

           5、技术体系失控问题:不同的开发团队使用不同的技术栈或者组件,造成公司内部的技术架构失控。甚至研发人员为追求时髦新潮技术,拿应用项目来试验新技术。

           。。。。。。  能列举出来还有多各种各样问题。

     

          架构设计的目的是为了解决系统复杂性带来的问题,其本质就是对系统进行有序化地重构以致符合当前业务的发展,并可以快速扩展。从上面架构的定义,也知道架构设计的作用涉及四方面:1、系统性思考的合理决策。2、明确的系统骨架。3、系统协作关系4、约束规范和指导原则。

    架构师通过理解业务,全局把控,选择合适技术,解决关键问题、指导研发落地实施,促进业务发展,提高效率。

     那什么样的系统要考虑做架构设计?  技术不会平白无故的出和自驱动发展起来,而架构的发展和需求是基于业务的驱动。

    1.  需求相对复杂.
    2.  非功能性需求在整个系统占据重要位置.
    3.  系统生命周期长,有扩展性需求.
    4.  系统基于组件或者集成的需要.
    5.  业务流程再造的需要.

     

    三、架构分类


    RUP4+1架构视图

    1995年,Philippe Kruchten在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文,引起了业界的极大关注,并最终被RUP采纳。即RUP4+1架构方法。该方法主要采用用例驱动,在软件生命周期的各个阶段对软件进行建模,从不同视角对系统进行解读,从而形成统一软件过程架构描述.

    该方法的不同架构视图承载不同的架构设计决策,支持不同的目标和用途:

    逻辑视图:用于描述系统软件功能拆解后的组件关系,组件约束和边界,反映系统整体组成与系统如何构建的过程。关注功能和逻辑层。

    开发视图:描述系统的模块划分和组成,以及细化到内部包的组成设计,服务于开发人员,反映系统开发实施过程。

    物理视图:描述软件如何映射到硬件,反映系统在分布方面的设计,系统的组件是如何部署到一组可计算机器节点上,用于指导软件系统的部署实施过程。

    处理流程视图:用于描述系统软件组件之间的通信时序,数据的输入输出,反映系统的功能流程与数据流程,通常由时序图和流程图表示。关注进程、线程、对象等运行时概念以及相关的并发、同步、通信等问题。

    运用4+1视图方法:针对不同需求进行架构设计

    TOGAF9架构分类

    TOGAF9来对架构分类:

    由于不同架构方法论,定义的架构分类也不同,RUP4+1架构方法主要是以架构生命周期为视角进行描述,而TOGAF9按架构涉及内容维度来描述。因此我结合两者细分为业务架构、应用架构、数据架构、技术架构, 代码架构, 部署架构。

         

         业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。 熟悉业务,形成业务架构,根据业务架构,做出相应的应用架构,最后技术架构落地实施。

    1、业务架构(俯视架构)

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

           没有最优的架构,只有最合适的架构,一切系统设计原则都要以解决业务问题为最终目标,脱离实际业务的技术情怀架构往往会给系统带入大坑,任何不基于业务做异想天开的架构都是耍流氓。

           所有问题的前提要搞清楚我们今天面临的业务量有多大,增长走势是什么样,而且解决高并发的过程,一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

    看看京东业务架构(网上分享图)  

         

    2、应用架构(剖面架构,也叫逻辑架构图):

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

    类似:

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

    应用架构图关键有2点:

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

        应用分层有两种方式:

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

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

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

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

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

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

    3、数据架构

    数据架构指导数据库的设计.  不仅仅要考虑开发中涉及到的数据库,实体模型,也要考虑物理架构中数据存储的设计。

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    数据是集中还是分布存储的?如何考虑分布式存储?

    数据架构图

     

     

    2

    领域模型到数据库表的转换?表结构关系的设计?

    逻辑模型

    物理模型

    ER图

    Power Designer

    Visio

     

    3

    实体如何设计?充血模型和贫血模型?

    UML类图

     

     

    4

    使用什么数据库?关系型还是非关系型?

    选型结果

     

    4、代码架构(也叫开发架构):

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

    代码架构主要定义内容:

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

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    分层结构设计

    分层架构图(开发架构图)

    各种绘图工具

    好的分层结构支持自动化测试

    2

    开发技术选项

    开发语言

    开发框架

    开发工具

     

    考虑商用产品、开源框架、自研框架

    3

    模块划分

    源码工程;Project目录结构;

    分包(分库)

     

     

    4

    开发规范

    开发/编码规范文档;

     

     

    5

    软件质量属性

    分析和决策结果

     

    考虑运行期和开发期软件质量属性,并权衡利弊进行决策。

    最好的样本是参考现有《阿里巴巴Java开发手册》。

     

    5、技术架构

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

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

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

     

    6、部署拓扑架构图(实际物理架构图):

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

    物理架构主要考虑硬件选择和拓扑结构,软件到硬件的映射,软硬件的相互影响。

     

    考虑的方面

    产出物

    工具

    说明

    1

    网络方面:网络拓扑;网络设备;安全机制

    拓扑图

    安全规范

     

     

    2

    性能方面:可靠性、可伸缩性

    需要什么样设备性能

     

     

    3

    部署方面:集中式还是分布式;组件部署

    部署图

     

     

     

     

    三、架构级别


    我们使用金字塔的架构级别来说明,上层级别包含下层:系统级、应用级、模块级、代码级。

    • 系统级,即整个系统内各部分的关系以及如何治理:分层。

    • 应用级,即单个应用的整体架构,及其与系统内单个应用的关系等。

    • 模块级,即应用内部的模块架构,如代码的模块化、数据和状态的管理等。

    • 代码级,即从代码级别保障架构实施。

    战略设计与战术设计

    基于架构金字塔,我们有了系统架构的战略设计与战术设计的完美结合:

    • 战略设计:业务架构用于指导架构师如何进行系统架构设计。

    • 战术设计:应用架构要根据业务架构来设计。

    • 战术实施:应用架构确定以后,就是技术选型。

     

    四、应用架构演进


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

     

    架构演进路程:单体应用->分布式应用服务化-> 微服务

     

    1、单体应用

    企业一开始业务比较简单,只应用某个简单场景,应用服务支持数据增删改查和简单的逻辑即可,单体应用可以满足要求。

    典型的三级架构,前端(Web/手机端)+中间业务逻辑层+数据库层。这是一种典型的Java Spring MVC或者Python Django框架的应用。其架构图如下所示: 

    针对单体应用,非功能性需求的做法:

       1、性能需求:使用缓存改善性能

       2、并发需求:使用集群改善并发

       3、读写分离:数据库地读写分离

      4、使用反向代理和cdn加速

      5、使用分布式文件和分布式数据库

    单体架构的应用比较容易部署、测试, 在项目的初期,单体应用可以很好地运行。然而,随着需求的不断增加, 越来越多的人加入开发团队,代码库也在飞速地膨胀。慢慢地,单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,维护成本越来越高。下面是单体架构应用的一些缺点:

    复杂性高

    以一个百万行级别的单体应用为例,整个项目包含的模块非常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。可想而知整个项目非常复杂。 每次修改代码都心惊胆战, 甚至添加一个简单的功能, 或者修改一个Bug都会带来隐含的缺陷。

    技术债务: 随着时间推移、需求变更和人员更迭,会逐渐形成应用程序的技术债务, 并且越积 越多。“ 不坏不修”, 这在软件开发中非常常见, 在单体应用中这种思想更甚。 已使用的系统设计或代码难以被修改,因为应用程序中的其他模块可能会以意料之外的方式使用它。

    部署频率低: 随着代码的增多,构建和部署的时间也会增加。而在单体应用中, 每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、 影响范围大、 风险高, 这使得单体应用项目上线部署的频率较低。 而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复,出错率比较高。

    可靠性差: 某个应用Bug,例如死循环、内存溢出等, 可能会导致整个应用的崩溃。

    扩展能力受限: 单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。例如,应用中有的模块是计算密集型的,它需要强劲的CPU; 有的模块则是IO密集型的,需要更大的内存。 由于这些模块部署在一起,不得不在硬件的选择上做出妥协。

    阻碍技术创新: 单体应用往往使用统一的技术平台或方案解决所有的问题, 团队中的每个成员 都必须使用相同的开发语言和框架,要想引入新框架或新技术平台会非常困难。

    2、分布式

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

    这时需要对系统按照业务功能模块拆分,将各个模块服务化,变成一个分布式系统。业务模块分别部署在不同的服务器上,各个业务模块之间通过接口进行数据交互。

    该架构相对于单体架构来说,这种架构提供了负载均衡的能力,大大提高了系统负载能力,解决了网站高并发的需求。另外还有以下特点:

    降低了耦合度:把模块拆分,使用接口通信,降低模块之间的耦合度。

    责任清晰:把项目拆分成若干个子项目,不同的团队负责不同的子项目。

    扩展方便:增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。

    部署方便:可以灵活的进行分布式部署。

    提高代码的复用性:比如Service层,如果不采用分布式rest服务方式架构就会在手机Wap商城,微信商城,PC,Android,iOS每个端都要写一个Service层逻辑,开发量大,难以维护一起升级,这时候就可以采用分布式rest服务方式,公用一个service层。

    缺点:系统之间的交互要使用远程通信,接口开发增大工作量,但是利大于弊。

     

    3、微服务

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

          微服务的特点:

    易于开发和维护: 一个微服务只会关注一个特定的业务功能,所以它业务清晰、代码量较少。 开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的,所以整个应用也会被维持在一个可控状态。

    单个微服务启动较快: 单个微服务代码量较少, 所以启动会比较快。

    局部修改容易部署: 单体应用只要有修改,就得重新部署整个应用,微服务解决了这样的问题。 一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。

    技术栈不受限:在微服务架构中,可以结合项目业务及团队的特点,合理地选择技术栈。例如某些服务可使用关系型数据库MySQL;某些微服务有图形计算的需求,可以使用Neo4j;甚至可根据需要,部分微服务使用Java开发,部分微服务使用Node.js开发。

    微服务虽然有很多吸引人的地方,但它并不是免费的午餐,使用它是有代价的。使用微服务架构面临的挑战。

    运维要求较高:更多的服务意味着更多的运维投入。在单体架构中,只需要保证一个应用的正常运行。而在微服务中,需要保证几十甚至几百个服务服务的正常运行与协作,这给运维带来了很大的挑战。

    分布式固有的复杂性:使用微服务构建的是分布式系统。对于一个分布式系统,系统容错、网络延迟、分布式事务等都会带来巨大的挑战。

    接口调整成本高:微服务之间通过接口进行通信。如果修改某一个微服务的API,可能所有使用了该接口的微服务都需要做调整。

    重复劳动:很多服务可能都会使用到相同的功能,而这个功能并没有达到分解为一个微服务的程度,这个时候,可能各个服务都会开发这一功能,从而导致代码重复。尽管可以使用共享库来解决这个问题(例如可以将这个功能封装成公共组件,需要该功能的微服务引用该组件),但共享库在多语言环境下就不一定行得通了。

         
       

    五、衡量架构的合理性


    架构为业务服务,没有最优的架构,只有最合适的架构, 架构始终以高效,稳定,安全为目标来衡量其合理性。

    合理的架构设计:

    1、业务需求角度

    1、能解决当下业务需求和问题

    2、高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题

    3、前瞻性设计: 能在未来一段时间都能以第2种方式满足业务,从而不会每次当业务进行演变时,导致架构翻天覆地的变化。

     

    2、非业务需求角度

    (一)、稳定性。指标:

    1. 高可用:要尽可能的提高软件的可用性,我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。

    (二)、高效指标:

    1. 文档化:不管是整体还是部分的整个生命周期内都必须做好文档化,变动的来源包括但不限于BUG,需求。

    2. 可扩展:软件的设计秉承着低耦合的理念去做,注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代,并且支持在适时对架构做出重构。

    3. 高复用:为了避免重复劳动,为了降低成本,我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。

    (三)、安全指标

    1. 安全:组织的运作过程中产生的数据都是具有商业价值的,保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段

    六、常见架构误区


    ●开高走落不到实处

    ● 遗漏关键性约束与非功能需求

    ● 为虚无的未来埋单而过度设计

    ● 过早做出关键性决策

    ● 客户说啥就是啥成为传话筒

    ● 埋头干活儿缺乏前瞻性

    ● 架构设计还要考虑系统可测性

    ● 架构设计不要企图一步到位

    误区1——架构专门由架构师来做,业务开发人员无需关注

    架构的再好,最终还是需要代码来落地,并且组织越大这个落地的难度越大。不单单是系统架构,每个解决方案每个项目也由自己的架构,如分层、设计模式等。如果每一块砖瓦不够坚固,那么整个系统还是会由崩塌的风险。所谓“千里之堤,溃于蚁穴”。

    误区2——架构师确定了架构蓝图之后任务就结束了

    架构不是“空中楼阁”,最终还是要落地的,但是架构师完全不去深入到第一线怎么知道“地”在哪?怎么才能落的稳稳当当。

    误区3——不做出完美的架构设计不开工

    世上没有最好架构,只有最合适的架构,不要企图一步到位。我们需要的不是一下子造出一辆汽车,而是从单轮车 --> 自行车 --> 摩托车,最后再到汽车。想象一下2年后才能造出的产品,当初市场还存在吗?

    误区4—— 为虚无的未来埋单而过度设计

    在创业公司初期,业务场景和需求边界很难把握,产品需要快速迭代和变现,需求频繁更新,这个时候需要的是快速实现。不要过多考虑未来的扩展,说不定功能做完,效果不好就无用了。如果业务模式和应用场景边界都已经比较清晰,是应该适当的考虑未来的扩展性设计。

     

    误区5——一味追随大公司的解决方案

    由于大公司巨大成功的光环效应,再加上从大公司挖来的技术高手的影响,网站在讨论架构决策时,最有说服力的一句话就成了“淘宝就是这么搞的”或者“腾讯 就是这么搞的”。

    大公司的经验和成功模式固然重要,值得学习借鉴,但如果因此而变得盲从,就失去了坚持自我的勇气,在架构演化的道路上迟早会迷路。

     

    误区6——为了技术而技术

    技术是为业务而存在的,除此毫无意义。在技术选型和架构设计中,脱离网站业务发展的实际,一味追求时髦的新技术,可能会将技术发展引入崎岖小道,架构之路越走越难。考虑实现成本、时间、人员等各方面都要综合考虑,理想与现实需要折中。

     

     

    七、架构书籍推荐


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

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

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

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

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

    3. 《架构即未来》

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

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

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

    5. 《聊聊架构》

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

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

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

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

     

    总结参考:

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

     

     

    展开全文
  • 微信技术总监分享架构设计高清完整PDF版

    万次下载 热门讨论 2012-05-15 09:17:26
    在技术架构上,微信是如何做到的?日前,在腾讯大讲堂在中山大学校园宣讲活动上,腾讯广研助理总经理、微信技术总监周颢在两小时的演讲中揭开了微信背后的秘密。
  • 系统架构设计师考试经验

    万次阅读 2017-11-02 10:27:04
    系统架构设计师是一个最终确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄清技术细节、扫清主要难点的技术人员。 系统架构设计师考试合格人员能够根据系统需求规格说明书,结合应用领域和技术...

    系统架构设计师是一个最终确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄清技术细节、扫清主要难点的技术人员。
    系统架构设计师考试合格人员能够根据系统需求规格说明书,结合应用领域和技术发展的实际情况,考虑有关约束条件,设计正确、合理的软件架构,确保系统架构具有良好的特性;能够对项目的系统架构进行描述、分析、设计与评估;能够按照相关标准编写相应的设计文档;能够与系统分析师、项目管理师相互协作、配合工作;具有高级工程师的实际工作能力和业务水平。

    1. 考试准备流程

    考试报名地址 网站比较奇葩,需要IE或者360,chrome不行

    报名流程

    1.1 报名

    1. 网站注册【大概9月份】
    2. 填写报名信息
    3. 上传照片【需要注意照片大小,照片清洁度等】
    4. 提交信息
    5. 等待审核
    6. 审核通过后,进行缴费【210块】
    7. 打印准考证【考试前一个礼拜,大概11月6号左右】
    8. 考场考试【11月11日】
    9. 然后等结果喽!

    1.2 考试

    • 上午9点-11点半【综合知识】

    75个单选题,满分75分,45分及格

    • 下午1点-3点【案例分析】

    1个必答题,剩下4道题选一道,满分75分,45分及格

    • 下午3点20-5点20【论文】

    4道题选一道进行论文书写,满分75分,45分及格

    2. 考试备考流程

    2.1 综合知识

    • 熟悉该年的考试大纲
    • 按照大纲,去熟悉教材【系统架构设计师考试全程指导-清华大学版】
    • 开始研究往年真题
    • 综合知识大概啥问题了

    2.2 案例分析

    • 需要平时知识储备【多琢磨原理的东西】

    2.3 论文

    • 模仿几篇美文,按照套路来
    展开全文
  • 4G网络架构

    万次阅读 2016-05-21 20:00:15
    1,4G是第四代移动通信技术,该技术包括TD-LTE和FDD-LTE两种制式,严格意义上来讲LTE只是3.9G,只有升级版的LTE Advanced才满足国际电信联盟对4G的要求。 4G是集3G与WLAN于一体,并能够快速传输数据、高质量、...
    
    

    14G是第四代移动通信技术,该技术包括TD-LTEFDD-LTE两种制式,严格意义上来讲LTE只是3.9G,只有升级版的LTE Advanced才满足国际电信联盟对4G的要求。

    4G是集3GWLAN于一体,并能够快速传输数据、高质量、音频、视频和图像等。4G能够以100Mbps以上的速度下载,比目前的家用宽带ADSL4兆)快25倍,并能够满足几乎所有用户对于无线服务的要求。

    2LTE网络结构如下:

    整个LTE网络从接入网和核心网方面分为E-UTRANEPC两个大的部分。相比于3G技术,对应于3G技术中的UTRANEPC部分。

    1)E-UTRANEvolved Universal Terrestrial RadioAccess Network

    E-UTRAN在系统性能和能力方面的研究目标主要是以下几点:

    A:更高的空中接口峰值速率以及频谱效率。

    B:在E-UTRAN中,eNodeB之间底层采用IP传输,在逻辑上通过X2 接口互相连接,即形成Mesh 型网络。这样的网络结构设计主要用于支持UE 在整个网络内的移动性,保证用户的无缝切换。而每个eNodeB 通过S1 接口和移动性管理实体/接入网关(MobilityManagement Entity (MME)/Serving Gateway(S-GW))连接,一个eNodeB 可以和多个MME/S-GW 互连,反之亦然。

    C:在E-UTRAN网络中,由于没有了RNC,整个E-UTRAN的空中接口协议结构与原来的UTRAN相比有了较大的不同,特别是不同功能实体的位置出现了很多的变化。原来由RNC承担的功能被分散到了eNodeBMME/S-GW上。

    2EPCEvolvedPacket Core

    EPC 核心网主要由移动性管理设备(MME服务网关(S-GW、分组数据网关(P-GW)、存储用户签约信息的HSS、策略控制单元(PCRF)等组成,其中S-GW P-GW可以合设,也可以分设。EPC 核心网架构秉承了控制与承载分离的理念,将分组域中SGSN 的移动性管理、信令控制功能和媒体转发功能分离出来,分别由两个网元来完成,其中,MME 负责移动性管理、信令处理等功能,S-GW 负责媒体流处理及转发等功能P-GW 则仍承担GGSN 的职能。LTE 无线系统中取消了RNC 网元,将其功能分别移至基站eNodeB 和核心网网元,eNodeB 将直接通过S1 接口与MMES-GW 互通,简化了无线系统的结构。

    34G网络架构的变化

    1)实现了控制与承载的分离,MME负责移动性管理、信令处理等功能,S-GW负责媒体流处理及转发等功能。

    2)核心网取消了CS(电路域),全IPEPCEvolved Packet Core,移动核心网演进)支持各类技术统一接入,实现固网和移动融合(FMC),灵活支持VoIP及基于IMS多媒体业务,实现了网络全IP化。

    3)取消了RNC,原来RNC功能被分散到了eNodeB和网关(GW)中,eNodeB直接接入EPCLTE网络结构更加扁平化,降低了用户可感知的时延,大幅提升用户的移动通信体验。

    4)接口连接方面,引入S1-FlexX2接口,移动承载需实现多点到多点的连接,X2是相邻eNB间的分布式接口,主要用于用户移动性管理;S1-Flex是从eNBEPC的动态接口,主要用于提高网络冗余性以及实现负载均衡。

     

    5)传输带宽方面:较3G基站的传输带宽需求增加10倍,初期200-300Mb/s,后期将达到1Gb/s

    43G4G系统参数的比较

     

     

     

    展开全文
  • 物联网平台架构设计

    万次阅读 多人点赞 2017-09-11 14:13:28
    用户如何管理,数据包如何解析,大数据如何展示等也是物联网模块中非常重要的部分,所以作者就根据自身工作中总结出来的建构在云端的物联网平台基本架构分享给大家,并基于此架构如何一步一步来开发
  • 架构设计(2)-架构设计原则

    万次阅读 2017-10-17 14:19:01
    如何设计出一个好的架构,不像数据公式或者定律,很难一概而就...一些好的架构设计原则可以确保设计决策在一定程度上能够满足需求。 一、形成架构原则的过程 形成架构原则的过程: 架构原则要SMART ...
  • 为什么要报考系统架构设计师考试

    万次阅读 多人点赞 2019-08-02 17:03:09
    一、强迫自己,去系统学习软件架构设计的理论,追踪业界架构设计的发展动态。去学习的动力有很多,如为了兴趣,为了工作,为了职位升迁,为了大幅提升薪水等。其实,为了应付考试,通过考试,也是学习知识的一种很好...
  • 前端架构设计

    千次阅读 2018-04-12 10:44:20
    作者结合自己在 Red Hat 公司的项目实战经历,探讨了前端架构原则和前端架构的核心内容,包括工作流程、测试流程和文档记录,以及作为前端架构师所要承担的具体开发工作,包括 HTML、JavaScript 和 CSS 等。...
  • 架构设计实例

    千次阅读 2016-02-21 15:15:01
    [网站原理与架构] [高可用可伸缩架构实用经验谈:四层模型解析] [从技术细节看美团的架构] from:http://blog.csdn.net/pipisorry/article/details/50708272 ref:
  • PHP深入理解-PHP架构布局

    千次阅读 2018-12-16 15:40:10
    本文基于《PHP 内核剖析》与 《PHP7底层设计与源码实现》所记笔记。 对PHP内核的深入理解有助于我们对PHP的整体认识,对于业务层初期发展我们可以只了解基本语言的逻辑就可以写出符合业务的代码,但是随着业务的发展...
  • java架构师学习路线图

    千次阅读 2019-04-04 14:22:22
    一个Java程序员不想要成为一个Java “old”程序员,唯一的出路就是学习Java技术的脚步永不停滞,让自己成为一个Java架构师,成为一个公司真正的技术大咖,平时上班泡泡茶、喝喝咖啡,度过了愉快潇洒的一天,每当所有...
  • 架构设计

    千次阅读 2014-06-05 16:52:21
    1.每个人都是架构师 2.对架构设计的理解 3.架构设计解决的问题 4.架构设计五视图 5.如何后期使用架构设计
  • 移动端游戏架构设计

    万人学习 2015-10-10 09:20:33
    目前很多开发者对于游戏架构设计一无所知,只是简单的把脚本与对象进行挂接,导致在后期开发中,版本维护,功能扩展非常不方便,现在网上出现了各种版本的热更新实现,比如Lua,JS,C#Light等, 该框架设计技术...
  • 课程主体部分从软件架构体系结构、架构设计、技术体系等角度出发,详细介绍了架构师区别于一般开发人员所需要掌握的架构设计方法论与相关实践,包括架构风格与模式、领域驱动设计、类与框架设计、分布式系统架构设计...
  • 架构设计(7)—如何设计一个架构

    万次阅读 2018-09-29 17:05:51
    那接下来就是如何着手开始做架构设计。 一、如何开始设计一个架构:方式方法 架构不是像平常写代码一样,对就是对,错就是错,它并无对错之分,是一个取舍的过程。当我们从0开始做架构的时候,的确是比较困难。...
  • 游戏架构 游戏架构设计(9)

    千次阅读 2014-04-22 16:14:42
    1.网络游戏MMORPG整体服务器框架,包括早期,中期,当前的一些主流架构 2.网络游戏网络层,包括网络协议,IO模型,网络框架,消息编码等。 3.网络游戏的场景管理,AI,脚本的应用等。 4.开源的网络服务器引擎 5.参考...
  • 风控系统架构设计

    万次阅读 2014-03-17 14:30:46
    风控系统架构设计
  • 软件架构设计---架构设计

    千次阅读 2018-09-17 21:46:29
    实现软件质量属性的战术,这些战术可以看做设计的... 通过架构模式,架构设计师可以借鉴和复用他人的经验,看看类似的问题别人是如何解决的。但不要把模式看成是一个硬性的解决方法,它只是一种解决问题的思路。...
  • 架构设计的原则

    千次阅读 2016-12-07 20:39:32
    本文是对《架构即未来》一书第12章的总结; 1. 书中总结了一个好的架构应该具备的特点,但是有些特点个人感觉是重复的,中间起来应该有以下3个特点: ...架构设计不应脱离实际,一个很美好但是无法实现的架构是
  • 监控平台架构设计

    万次阅读 2014-05-29 23:31:56
    监控平台架构设计
  • 架构设计(8)—高可用架构设计

    千次阅读 2019-01-14 17:58:37
    高可用架构设计总结: 前言:海恩法则和墨菲定律 海恩法则 · 事故的发生是量的积累的结果。 · 再好的技术、再完美的规章 , 在实际操作层面也无法取代人自身的素质和责任心 。 墨菲定律 · 任何事情都没有...
  • 领域驱动实践总结二:架构分析与代码设计 领域驱动设计DDD是一种设计思想,它可以同时指导中台业务建模和微服务设计(中台本质是业务模型,微服务是业务模型的系统落地),领域驱动设计强调领域模型和微服务设计的一体...
  • 架构设计之路自主编写Web开发框架

    万人学习 2016-01-17 15:36:57
    以从零开始编写一个类似Struts2框架的方式来思考和架构,手把手带你从开始分析到结构设计到终实现的整个过程,完成Struts2框架的核心内容,从而更好的理解Struts2框架的设计理念和提升自身的框架编写能力。...
  • 架构设计之CS架构

    千次阅读 2018-11-13 14:56:46
    架构设计之CS架构
  • 高性能微服务架构设计模式

    千人学习 2019-12-26 17:34:19
    本课程是对分布式微服务架构设计模式进行讲解,以亿级QPS的电商网站为例对常见的技术架构进行分析,从高性能,高可用的角度比较各种方案的优劣点,重点讲解使用CQRS模式怎么进行高性能的微服务架构设计,读者学习本...
  • 架构设计——架构知识体系

    万次阅读 多人点赞 2018-08-23 13:45:58
    架构设计——架构知识体系   1、什么是架构和架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。 我们主要针对互联网服server系统...
  • 系统架构设计

    万次阅读 2018-09-06 14:03:25
    什么是架构架构就相当于我们要盖一栋楼时的框架。系统架构就类似于工程的结构。 一、传统架构 用传统的架构,1000并发量需要2太服务器做tomca集群 但是由于系统用的人越来越多,并发量越来越大待到并发...

空空如也

1 2 3 4 5 ... 20
收藏数 699,433
精华内容 279,773
关键字:

架构设计