素材巴巴 > 程序开发 >

微服务架构设计案例分析- 陆金所网站

程序开发 2023-09-21 06:41:55

前言:本文引用自https://www.cnblogs.com/Leo_wl/p/4917489.html 微服务架构设计案例

1. 架构的选择

小项目:传统的单体应用,将所有功能的表示层、业务逻辑层,数据访问层,包括静态资源等等全部糅合在一个工程里面,编译,打包,部署在单台服务器上上线,比如打成war包放在Tomcat的webapp目录中部署项目。

大项目:微服务架构:就是将原来的单体应用按义务范围来进行划分,划分为多个小model,每个微服务运行在自己的进程中,不相互影响,通过完全自动化部署来独立部署。并使用轻量级机制通信,通常是HTTP RESTUFUL API。可对各个微服务进行集中管理。这些小model可以使用不同的编程语言,以及不同的存储技术。微服务架构是分布式架构。

2. 架构设计文档

需求分析
系统分析
逻辑架构
开发架构
运行架构
物理架构

例如开发金融网站https://www.lu.com/

1)需求分析


需求分析表-陆金所 分类功能质量约束前端用户首页产品展示及时响应、搜索引擎优化无上证指数显示及时响应、搜索引擎优化实时同步上证指数.....前端用户会员中心账户总览及时响应,安全性无充值、取现及时响应,安全性无.....前端用户会员俱乐部活动类玩法及时响应、搜索引擎优化目前包括:刮刮乐、抽奖、竞猜、竞拍.....后端运维不同产品的发布管理及时响应,可扩展性无.....

2). 系统分析

按需求结合企业的运营目标,提供宏观的系统要求分析
例如陆金会上线5年后,预估系统运营状况:
产品更替:更新,上架新的金融产品(期货,现货交易)
注册人数:3000万
年营业额:1000亿
网站访问数量:3000万PV
产品购买并发:1000 QPS

分类需求子系统及服务实现技术用户前端首页及其它产品展示、产品搜索、促销活动、推荐服务 平台商品服务集群部署、高速缓存、分布式缓存、搜索引擎技术、静态化广告图片、公告、帮助中心、媒体报道、常见问题投资某产品平台会员服务集群部署、消息队列、实时计算.....

如上所述,要支持运营目标的陆金所平台,可以分为大小十几个服务和子系统。系统划分的依据一方面是职责,一方面跟实现技术有关,同一职责下实现技术不同会被划分为两个服务,比如购买商品和商品展示原本属于同一个大的领域,但其因为实现技术和质量要求不同需要划分为两个模块。这是因为微服务和传统SOA最大的区别就是技术实现的个性化,只有个性化才能做好做专,并节省成本。另外根据系统分析,我们需要将第三方调用的地方抽取为服务,比如支付,将这些第三方调用抽取为一个单独的服务首先也是基于职责考虑,其次是基于稳定性考虑,因为调用第三方的东西通常存在很大的不稳定性,当某一厂商提供的API不能用时,我们的系统需要自动切换到可用的API。用户购买产品产生订单相关数据,订单数据关系到商品和用户两方面,如果是超高并发的系统,用户购买行为需要单独的服务,但限于互联网金融的特殊性-不会在同一时刻产生大量交易,我们将订单服务合并到用户账户服务,因为从数据角度来讲,订单属于每一个用户。

3) 逻辑架构

在这里插入图片描述十几个子系统分别分布在服务层、服务监控与治理、表现层。实体层和接口访问层虽然属于“层”,但它们并不单独发布,而是使用Jar包类库的方式提供给其它服务调用,是逻辑上的层。业务服务模块具有模块化,构件化的特点,并可以以各种不同的协议发布服务,包括SOAP、RMI、REST、JMS等。

4)开发架构

在这里插入图片描述所需公共模块工程:
在这里插入图片描述
开发环境:

编码:UTF-8

工具:Myeclipse 10

SVN:Site-1.8.22

注释插件:Jautodoc_1.8.0

Web服务器:Tomcat7

JDK: JDK1.7、 Java EE 5

开发环境:Maven 3

开发技术选型:

表现层:Bootstrap+Html+Jquery

MVC框架:Spring MVC 3.2

安全框架:Spring security 3.2

Rest接口实现:Spring MVC Rest

持久层:Mybatis3.2

缓存框架:Ehcache 2.6、Redis

日志管理:SLF4J 1.7、Log4j

数据库:MySql 5.5

5)运行架构

此架构设计视图的关注点是控制流组织。运行架构考虑一些非功能性的需求,如性能和可用性。它解决并发性、分布性、系统完整性、容错性的问题,以及逻辑视图的主要抽象如何与进程结构相配合在一起-即在哪个控制线程上,对象的操作被实际执行。
在这里插入图片描述主要控制流包括:

l 页面访问控制流

由前端浏览器发起请求,部分请求首先会到缓存里查询,如果缓存里有结果则返回,如果没有缓存内容,则继续请求web服务器。也有部分无需缓存的请求直接访问web服务器获取数据。

l 日志采集

操作日志采集有两条控制流。一条是页面的采集js,直接将用户请求发送至日志采集接口,由日志采集接口提交给消息队列,再由日志采集模块从消息队列里获取数据并保存。另外一条是在web服务器层面拦截访问请求并提交给消息队列,并由日志采集模块获取和处理。

l 自动对账

由接口访问层拦截需要记账的操作,并转换成记账凭证提交到消息队列,由自动对账模块从消息队列中获取数据并保存。自动对账功能是由定时任务触发,由自动对账服务按规则进行对账计算,如果需要预警则产生预警数据。

l 手机APP访问

由手机app发起,部分请求首先会到缓存里查询,如果缓存里有结果则返回,如果没有缓存内容,则继续请求web服务器。也有部分无需缓存的请求直接访问web服务器获取数据。

l 运维管理

由浏览器发起请求,考虑到并发情况并不是很大,可不经过缓存服务器,直接与web服务器运维服务交互。

6)物理架构

此架构设计视图的关注点是物理节点(Node)分布,以及软件到硬件的具体映射关系。
在这里插入图片描述主要关键技术:

l 负载均衡

1)采用负载均衡器来实现硬件级的四层交换负载均衡,或采用LVS来实现软件的四层交换负载均衡。并通过nginx实现反向代理服务器集群。

  1. 使用zookeeper实现业务服务的负载均衡。

l 缓存

1)系统使用Varnish 集群以作为静态页面和图片的高速缓存。

2)使用Redis集群作为业务层的高速缓存,Redis具有高并发、高可用等特性。

l 文件存储

鉴于平台文件存储业务并不复杂,通过NFS实现文件存储集群。

l 消息队列

系统使用高并发、高稳定性消息队列rabbitmq实现异步消息处理。

l Docker集群

系统采用最新的虚拟机技术docker作为服务集群发布的载体。


标签:

素材巴巴 Copyright © 2013-2021 http://www.sucaibaba.com/. Some Rights Reserved. 备案号:备案中。