远憬建站,做网站后台都要自己写吗,宁波模板网页制作,重庆有什么好玩的游乐场一、架构总原则 1. 大中台小前台的架构思路 2. 业务中台采用领域驱动设计#xff08;DDD#xff09;#xff0c;在其上构建业务能力SAAS#xff0c;持续不断进行迭代演进。 3. 平台化定位#xff0c;进行了业务隔离设计#xff0c;方便一套系统支撑不同玩法的业务类型和便…一、架构总原则 1. 大中台小前台的架构思路 2. 业务中台采用领域驱动设计DDD在其上构建业务能力SAAS持续不断进行迭代演进。 3. 平台化定位进行了业务隔离设计方便一套系统支撑不同玩法的业务类型和便于定制化扩展。 4. 前后端分离通过服务接入层进行路由适配转发。 5. 天然的分库分表消息解耦和分布式缓存设计支持弹性扩容以支持大数据高并发场景。 二、系统逻辑架构图 2.1、电商中台 中台部分在逻辑上分成了基础能力和平台产品两层这样做的好处是基础能力层聚焦于稳定收敛的业务模型和基础服务本身不会随着业务和前台产品的调整发生变化可以简单理解为业务模型的DAO。平台产品层则专注于通过流程编排类的技术手段将基础能力构建成业务的解决方案解决共性和个性化的问题。我们将以交易的设计为例来说明这个分层理念。通过对电商交易业务的深入分析 可以确定几乎所有的交易都会涉及下图中所有的领域库存优惠价格…而单看每个域玩法都是很少变化的将这些域的基础能力完全可以沉淀下来形成原子的基础能力通过扩展点方式应对将来特殊的场景个性化扩展。 平台产品层为了应对不同的交易场景一口价拍卖货到付款预售…将原子的基础能力编排成满足不同场景的解决方案以服务的方式透出出去。 2.2、服务接入层 服务接入层是连接前台产品和中台产品层的纽带, 实质就是之前的web 应用不同的是现在前后端分离后只包含 java 代码使用springBoot web。做参数转换路由分发调用中台服务结果封装。这块需要做好前后端的交互规范请求路由映射规范web工程目录结构负载均衡方案跨越问题和安全问题
2.3、公用基础组件 沉淀和抽象出通用独立的公共基础组件。 1、数据访问组件 抽象封装分库分表访问读写分离主备切换。 2、消息中间件组件这块的选择非常多就开源的就有activeMQ,RabbitMQ,RocketMQ,Kafka等等, 再加上阿里云AWS, 腾讯云等提供的和对应的云版本会非常多如果不对这块做封装对其上应用做透明化处理后期做这块的适配调整就会非常痛苦特别是这套系统会在不同环境中进行部署时。 3、地址库组件 统一地理地址相关的服务如果是有拓展国际市场的需求这块会显得的非常重要不同文化背景的国家在这块的差异会非常大同时国内也涉及3级4级和5级地址的问题。 2.4、云服务设施容器层 如果技术团队不是非常大又没有较强的运维技术人员建议不要购买物理机自己搭建环境而是直接使用阿里云这些比较成熟的ECS和其他云服务这样会节省很多时间成本和一些耗时的运维工作让其专注于业务产品的研发同时使用docker 容器部署应用不仅需要的机器数量比较少而且部署非常便捷高效。
2.5、业务前台产品 ios ,android APP , H5 APP ,PC 站点微信支付宝小程序 都是属于这层前台产品主要是根据业务形态和产品的定位来进行构建。对于电商业务来说主要是指移动APP商城H5商城PC商城 小程序商城。将以小程序为例来说明。 为了适应小程序社交电商这样的热点加上有这么优秀的一套电商中台系统不搞出点有么有样的电商前台产品不是很没有道理为此想破脑袋我们把电商和送礼结合了起来做了“礼尚往来”的小程序下面是产品的截图。 2.6、稳定和安全保障系统 对电商这类在线交易系统流量会随着运营活动的波动非常大特别是到了双11这类大活动的时候流量的峰值会是平时的几十~几百倍一些接口会放大的更大核心系统的系统指标流量接口调用量和rt, 以及限流和异常的监控就显得非常重要了。在几年之前只有BAT 几个大的公司有能力在这方面做的不错随着全民参与的这种大型促销活动推动技术的进步以及开源社区和一些大厂将类似方案回馈到开源社区目前一个小的技术团队做好这块也没有什么难度了。现将我们用到的框架做个简单的介绍更多细节请参考官方文档。 1、sentinel是面向分布式服务架构的轻量级流量控制产品主要以流量为切入点从流量控制、熔断降级、系统负载保护等多个维度来帮助您保护服务的稳定性。 该系统已经过阿里内部双11多年的验证稳定性和可靠性非常不错已于最近开源。 2、ubbokeeper dubbo的官方监控dubbo-monitor-simple 在性能上表现非常不好经常卡死对比了几个成熟的框架后最终确定使用dubbokeeper. dubbokeeper社区版dubboadmin,包括了应用管理动态配置统计信息服务监控和zk信息查看功能。 3、pinpoint:现在基于微服务的架构一个请求从用户发起到响应中间调用链路非常长跨越数十个系统很正常并且路径非常多要定位一个比较耗时的响应不利用工具是非常低效的。Pinpoint这样的 工具 就是为处理这个问题出现的Pinpoint的优点是对代码零侵入运用JavaAgent字节码增强技术追踪每个请求的完整调用链路。 4、Telegraf influxDB Grafana主要用来实现业务数据的实时监控方案如交易额的不正常波动订单量的突然下跌等。 5、Telegraf 是收集数据的代理程序可以根据业务需要添加插件扩展服务收集到的数据写入分布式时序数据库influxDB,再通过grafana 可视化的展示出来。 2.7、工程结构 逻辑结构映射到物理的工程结构每个逻辑单元对应为一个子工程如果是用idea 开发就是一个model, 当然model 里边会有子model至于需要打包构建多少个系统其决定性因素是你团队的规模如果团队规模较少中台系统合并到3-4个左右就足够了如果团非常大一个团队负责一个业务板块的并为其构建多个系统也是非常正常的像较大的电商公司负责商品的就是一个团队商品相关的系统就有数10个。以交易为例可以将交易的系统合并为一个系统但在工程的组织结构上是对立的方便将来的拆分。 转载地址
1、电商系统“大中台小平台”架构设计
