架构设计 ORM架构 MVC架构 RPC架构 SOA架构 架构演变过程 亿级流量架构设计 大型架构设计实现 项目的容灾的部署方案

目录

1.ORM架构

2.MVC架构

3.RPC架构

4.SOA架构

5.架构的演变

项目的容灾的部署方案

6.亿级流程架构设计

1.初级阶段

2.中级阶段

3.后期阶段


1.ORM架构

叫对象关系映射(Object Relational Mapping) 。是一种机构格式。(实体类映射数据库表)代表框架:hibernate 、mybatis、ibatis。

2.MVC架构

M:mode 模型、 指的也就是业务代码,V:view 视图、指的是用户看到的界面,C: controller 控制器、指的是用户与业务的交互控制(用户与业务之间的桥梁)。用户调控制层,控制调业务,业务返回给控制,控制返回给用户

3.RPC架构

分布式服务框架。dubbo、spring cloud等框架。

4.SOA架构

面向服务架构。soa架构的特点:粗粒度、低耦合,服务之间通过简单、精确定义接口进行通讯,不涉及底层服务接口与通讯模型。服务层是soa的基础。

5.架构的演变

这里放一张dubbo的架构图。

这张图已经说了系统架构的一个设计方向。(每个人可以根据公司的业务需求合理的使用相应的架构方案)。


项目的容灾的部署方案

 提一下项目的容灾。(这里也是根据自己公司的实际需求来合理的配置)

1.就是一个主项目(比如系统宕机,相应的时间公司也可以接受,也就可以这样部署(节约成本))

2.一主一备(比如系统宕机,公司不想影响业务,可以采用一主一备的部署方案(主的配置高点、备的配置可以低一些。等主系统启动起来,对用的业务也就到了主服务了)。)

3.双机部署(主要来做负载均衡,与方案2大致一个意思)

4.两地三中心(对于大型项目来说,以上的部署方案也就不使用了)很牛逼的部署方案。


6.亿级流程架构设计

从以下三个方面描述每个阶段的相应架构设计。

1.初级阶段

这里指的的是,新项目的开始或公司一些小规模的软件产品。

现阶段的项目大部分都是单机项目。大部分都是业务逻辑CRUD操作。现在这个阶段大部分都选择前后端分离开发方式,前端H5(或一些现成前端框架vue等、根据现有人员的技术基础而定)、后台端 spring boot+jdk1.8(稳定) (这里也是根据技术人员的基础而定的,就用spring MVC 也是可以的,就是配置麻烦点)、数据库MySQL(选这个、经济实惠、开发称成本低)。现在这个初始阶段的技术框架就有了:H5(vue) + spring boot +mysql

项目开发完成就需要部署上线。这里部署到Linux服务器上。前端项目打包需要放到服务器上这里就选用nginx(这里是应它的方向代理:程序的接口调用都到了nginx服务器上了,nginx再去获取后台数据然后返回给前端),当然也可以就是当静态资源服务器,前端请求直接与后端交互。

这里所有结构都出来了,前端H5、后端 spring boot、数据库MySQL、服务器Linux、JDK1.8.

这里以OA系统为例的简单的架构图(如果考虑容灾,查看以上方案)。这里还有很多优化方案(增加缓存等)

这是双机的一个简单的图,在这个就要session的共享的问题,这样就可以提高系统承载量(暂时的、这个也只是项目的发展的一个阶段)

 

2.中级阶段

当公司的业务发展到一定的阶段以上的架构不再适用(假设你的模块业务需求非常大),这个阶段咱们往微服务上靠。

什么叫微服务

就是小的服务模块,精髓就是这个微。 微服务不是适应所有企业,没个企业根据自己的实际需求来设计自己的服务架构。

比如说一个新项目上来就在微服务起步,由于人员多、机器费用也多、商业模式问题(不确定性)、开发时间(长)、项目周期等因素都会影响到项目的落地。可能公司找了好多人、也买了好多机器,打算开发项目呢,发现钱不够了(指的是多方面消耗,或者项目开发快结束了发现商业模式有问题、项目可能需要从新来。(这里指的是一些新项目,也不是所有的项目),有的公司牛,什么对于人家来说,那都不是事。

单机项目到微服务的过程

这里指按照微服务方向升级方案,不考虑增加机器的方式。

这个时候,我们单体应用不能满足我们的需要了,我们首先会在查看时哪里的瓶颈导致系统性能。

假设是应为某个模块的业务大增,导致影响了整体的系统。这个时候我们就把这个模块单独拿出来,构成一个新的项目。这个两个项目之间的调用同过resful来调用,然后用的信息可能放到缓存中,供这连个项目来调用,如果我们的数据库到了性能瓶颈了,我们也会考虑在数据库与应用之间加上缓存(不如redis)来缓解数据库的压力,(这个可能涉及到redis的击穿、穿透、雪崩、数据预热等问题),再有压力我们可能会考虑分库分表数据库集群等。

这个里已经把单个应用分成了两个,这里把这个过程再重复一遍,就有才分成4个应用,再来一遍变8个,再来一遍16个。(这里只是假设,实际上还是跟自己需要来拆分的)

等这些应用变多的时候,我们管理起来就非常的麻烦,这里我们就会涉及到自动化部署。这里服务都部署到环境中了,这里这么多服务我怎么知道哪个应用是正常的哪个是不可用的,这是就会又用到了注册中心。因为每个应用都有三套配置文件,管理起来非常麻烦,这里就又用到了配置中心。当这么多的应用在部署的时候,又需要一个统一的端口,这就又用到了网关

微服务的架构设计

3.后期阶段

(待更新。。。)

Guess you like

Origin blog.csdn.net/yu1xue1fei/article/details/114583291