架构目标

  1. 高可用性

整体系统可用性最低99.9%,目标99.99%。全年故障时间整个系统不超过500分钟,单个系统故障不超过50分钟。

  1. 高可扩展性 系统架构简单清晰,应用系统间耦合低,容易水平扩展,业务功能增改方便快捷。

  2. 低成本 增加服务的重用性,提高开发效率,降低人力成本;

  3. 最终一致性

服务设计能满足数据最终一致性,能方便、快捷的满足三方、或者对方对账需求。

  1. 质量要求

我们要求在系统设计时候要兼顾下面的各个质量要求

图片

架构总体原则

图片

DID原则解释

Design(D)设计20倍的容量;Implement(I)实施3倍的容量;Deploy(D)部署1.5倍的容量

原因:DID为产品扩展提供了经济,有效,及时的方法

要点:在早期考虑可扩展性可以帮助团队节省时间和金钱。在需求发生大约一个月前实施(写代码),在客户蜂拥而至的几天前部署。

例子:“什么时候该在可扩展性上投入”有些轻率的回答是,最好在需要的前一天投入和部署。如果你能够多做到达需要改善可扩展性方案的前一天部署,那么 这笔投资的时机最佳,而且有助于实现公司财务和股东利益的最大化。 让我们面对现实,及时投入和部署根本就不可能,即使可能,也无法确定具体的时间,而且会带来很多风险。

DID(设计-实施-部署):思考问题和设计方案,为方案构建系统和编写代码;实际安装或者部署方案。

设计(Design):DID方法的设计(D)阶段聚集在扩展到20倍和无限大之间,通过如今可扩展性大会,把领导者和工程师团队聚集在一起,共同讨论产品的扩展瓶颈,这是在DID设计阶段发现和确定需要扩展部分的一个好办法。

实施(I,Implement):我们把规模需求的范围缩小到更接近现实,例如当前规模的3~20倍。

部署(D,Deploy):在部署阶段资产的成本较高,如果是一家适度高增长的公司,也许我们可以把最大产能提高到1.5倍;如果是一家超高增长的公司,也许我们可以把最大产能提高到5倍。扩展具有弹性,它既可以扩张也可以收缩,因此灵活性是关键,因为你需要响应客户的请求,随着规模的收缩和扩张,在系统之间调整容量

架构设计原则

  1. 业务平台化
  • 业务平台化,相互独立。 如交易平台、仓储平台、物流平台、支付平台、广告平台等
  • 基础业务下沉,可复用。如用户、商品、类目、促销、订单等 (参考目前核心系统)。
  1. 核心业务、非核心业务分离

核心业务与非核心业务分离,核心业务精简(利于稳定),非核心业务多样化。

  1. 隔离不同类型的业务
  • 交易业务是签订买家和卖家之间的交易合同,需要优先保证高可用性,让用户能快速下单
  • 对高并发要求很高的业务,应该跟普通业务隔离
  1. 区分主流程、辅流程

分清哪些是主流程。运行时,优先保证主流程的顺利完成,辅流程可以采用后台异步的方式。避免辅流程的失败导致主流程的回滚。

应用架构设计要点

  1. 稳定性原则
  • 一切以稳定为中心
  • 架构尽可能简单、清晰
  • 不过度设计
  1. 解耦、拆分
  • 稳定部分与易变部分分离
  • 核心业务与非核心业务分离
  • 主业务与辅业务分离
  • 应用与数据分离
  • 服务与实现细节分离
  1. 抽象化
  • 应用抽象化:应用只依赖服务抽象,不依赖服务实现细节、位置
  • 数据库抽象化:应用只依赖逻辑数据库,不需要关心物理库的位置和分片
  • 服务器抽象化:应用虚拟化部署,不需要关心实体机配置,动态调配资源
  1. 松耦合
  • 同步调用时,需要设置超时时间、对调用异常时候的failover处理。
  • 非核心业务尽量异步化:核心、非核心业务之间,尽量异步解耦。
  • 跨业务线(比如分期乐、桔子、鼎盛间)调用需要采用HTTP接口方式,避免底层业务逻辑耦合和依赖。
  1. 容错设计
  • 服务自治:服务能彼此独立修改、部署、发布和管理,避免一个服务发生灾害引发连锁反应(一定要对mq、rpc、db、redis的异常容错处理、异常包括超时、业务异常、系统异常等)。
  • 集群容错:应用系统集群,避免单点。
  • 多机房容灾:多机房部署,多活。

6 数据的一致性原则

  • 小规模分布或不分布的业务确保可用、数据可靠、一致,即A & C兼顾;
  • 中型分布系统需要考虑【BASE-最终一致性】,如果涉及到订单、交易、清结算等数据敏感场景,保持数据最终一致性是最基本原则;
  • 大规模分布式系统在不涉及订单、交易、清结算等数据敏感场景上可以考虑【有损服务】;。

架构分解原则

图片

架构依赖原则

  1. 依赖稳定部分
  • 稳定部分不依赖易变部分
  • 易变部分可以依赖稳定部分
  • 要求:避免循环依赖
  1. 跨域弱依赖

跨业务域调用时,尽可能异步弱依赖

  1. 基本服务依赖
  • 基本服务不能向上依赖流程服务
  • 组合服务、流程服务可以向下依赖基本服务
  • 条件:基本服务稳定
  1. 平台服务依赖
  • 平台服务不依赖上层应用
  • 上层应用可依赖平台服务
  • 条件:平台服务稳定
  1. 核心服务依赖
  • 核心服务不依赖非核心服务
  • 非核心服务可依赖核心服务
  • 条件:核心服务稳定

 

posted @ 2023-11-11 20:44 古道轻风 阅读(500) 评论(0) 推荐(0) 编辑
摘要: 几年前,我被问到“你是如何变成一名架构师的?”。基于这个话题,我们讨论了很多,比如必要的技术、经验以及所需要的知识储备等。这一次讨论促使我开始思考要成为一名架构师应该具备和学习的东西有哪些,成为一个优秀的架构师应该具备哪些能力和做哪些事情。为此我查阅资料,走访各位大佬,当然也结合自己的经历,最终我输 阅读全文
posted @ 2023-10-24 08:30 古道轻风 阅读(1041) 评论(0) 推荐(1) 编辑
摘要: 一、前言 - ChatGPT真的产生心智了吗? 来自斯坦福大学的最新研究结论,一经发出就造成了学术圈的轰动,“原本认为是人类独有的心智理论(Theory of Mind,ToM),已经出现在ChatGPT背后的AI模型上”。所谓心智理论,就是理解他人或自己心理状态的能力,包括同理心、情绪、意图等。这 阅读全文
posted @ 2023-10-22 08:47 古道轻风 阅读(430) 评论(1) 推荐(2) 编辑
摘要: 先抛一下结论:在满足实时性的条件下,不存在两者完全保存一致的方案,只有最终一致性方案。根据网上的众多解决方案,总结出 6 种,直接看目录: 不好的方案 1、先写 MySQL,再写 Redis 如图所示: 这是一副时序图,描述请求的先后调用顺序; 橘黄色的线是请求 A,黑色的线是请求 B; 橘黄色的文 阅读全文
posted @ 2023-10-21 11:21 古道轻风 阅读(634) 评论(2) 推荐(1) 编辑
摘要: 怎么才能很好地避免低级故障?以下规范在大型互联网公司经过了充分验证,尤其适用于并发量大、数据量大的业务场景。 在设计数据库技术方案时,我们是有自己的设计理念或者原则,还是更多依据直觉去设计?是否曾经懊悔线上发生过的一次低级故障?是否思考过怎样才能避免?设计规范的价值在于提供了一份工作检查清单,我们不 阅读全文
posted @ 2023-10-20 08:28 古道轻风 阅读(507) 评论(1) 推荐(1) 编辑
摘要: 一、主从架构 为什么我们要进行读写分离?个人觉得还是业务发展到一定的规模,驱动技术架构的改革,读写分离可以减轻单台服务器的压力,将读请求和写请求分流到不同的服务器,分摊单台服务的负载,提高可用性,提高读请求的性能。 上面这个图是一个基础的Mysql的主从架构,1主1备3从。这种架构是客户端主动做的负 阅读全文
posted @ 2023-10-19 08:25 古道轻风 阅读(772) 评论(1) 推荐(1) 编辑
摘要: 天带来的是架构活动中的常见原则,在我们平时做技术方案,非功能设计时一定需要铭记于心这些方法论。 架构目标 高可用性 整体系统可用性最低99.9%,目标99.99%。全年故障时间整个系统不超过500分钟,单个系统故障不超过50分钟。 高可扩展性 系统架构简单清晰,应用系统间耦合低,容易水平扩展,业务功 阅读全文
posted @ 2023-10-18 08:27 古道轻风 阅读(191) 评论(0) 推荐(0) 编辑
摘要: 很多同学技术能力很强,架构设计也做得很好,但是在给别人讲解的时候,总感觉像是“茶壶里煮饺子,有货倒不出”。 其实,在为新员工培训系统架构、给领导汇报技术规划、上技术大会做演讲或者向晋升评委介绍工作贡献的时候,如果你能画出一张优秀的 软件系统架构图,就可以大大提升自己的讲解效果,让对方轻松地理解你想表 阅读全文
posted @ 2023-10-17 08:23 古道轻风 阅读(459) 评论(0) 推荐(2) 编辑
摘要: 当谈到架构的高可用时,无论是高可用计算架构,还是高可用存储架构,其本质的设计目的都是为了解决部分服务器故障的场景下,如何保证系统能够继续提供服务。但在一些极端场景下,有可能所有服务器都出现故障。例如,典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障,或者业务整体瘫 阅读全文
posted @ 2023-10-16 08:31 古道轻风 阅读(405) 评论(0) 推荐(0) 编辑
摘要: 聊聊从单体到微服务架构服务演化过程 单体分层架构 在 Web 应用程序发展的早期,大部分工程是将所有的服务端功能模块打包到单个巨石型(Monolith)应用中,譬如很多企业的 Java 应用程序打包为 war 包,最终会形成如下的架构: 巨石型应用易于搭建开发环境、易于测试、易于部署;其缺陷也非常明 阅读全文
posted @ 2023-10-15 08:15 古道轻风 阅读(258) 评论(0) 推荐(0) 编辑
摘要: 具体以电子商务网站为例, 展示web应用的架构演变过程。 1.0时代 这个时候是一个web项目里包含了所有的模块,一个数据库里包含了所需要的所有表,这时候网站访问量增加时,首先遇到瓶颈的是应用服务器连接数,比如tomcat连接数不能无限增加,线程数上限受进程内存大小、CPU内核数等因素影响,当线程数 阅读全文
posted @ 2023-10-14 08:53 古道轻风 阅读(163) 评论(0) 推荐(0) 编辑
摘要: 工具地址:GitHub - dotnet/try-convert:帮助 .NET 开发人员将他们的项目移植到 .NET Core! 这是一个简单的工具,有助于将.NET Framework项目迁移到.NET Core。 如何使用它 在此处将其作为全局工具安装: dotnet tool install 阅读全文
posted @ 2023-10-13 08:25 古道轻风 阅读(762) 评论(1) 推荐(1) 编辑
摘要: 一 .netframework程序迁移到.netcore5.0对于.netframwork程序想要升级为.netcore5.0的方法,微软官方也给出了方法见 https://docs.microsoft.com/en-us/dotnet/desktop/winforms/migration/?vie 阅读全文
posted @ 2023-10-12 14:03 古道轻风 阅读(1557) 评论(0) 推荐(2) 编辑
摘要: 一、引言 在当今数字化时代,零售业正迅速发展,消费者的购物行为和期望发生了巨大的变化。为了满足不断增长的需求,零售企业必须构建高度灵活、稳健可靠的商品系统。 本文将深入探讨零售商品系统的底层逻辑,聚焦领域驱动设计(DDD)和复杂业务系统架构经验,揭示其在零售业务中的应用和价值。 二、面临的挑战 商品 阅读全文
posted @ 2023-10-11 08:36 古道轻风 阅读(274) 评论(0) 推荐(0) 编辑
摘要: 今天我们来谈一谈TDD 和 BDD 两项实践。我们先来说说 TDD,也就是测试驱动开发(Test Drvien Development)。 TDD 的节奏 或许你已经迫不及待地要举手了:“TDD 我知道,就是先写测试,后写代码。”但真的是这样吗?严格地说,“先写测试、后写代码”的做法叫测试先行开发( 阅读全文
posted @ 2023-10-10 08:24 古道轻风 阅读(601) 评论(0) 推荐(0) 编辑
摘要: 一起学习下架构的视角。 架构的视角 在笔者的知识体系中,实际上将架构分为业务架构、应用架构、云基础架构这几大类,业务架构主要着眼于控制业务的复杂性,基础架构着眼于解决分布式系统中存在的一系列问题。无论何种架构,都希望能实现系统的可变的同时保障业务的高可用。 很多时候架构的视角/分类没有明显的边界,通 阅读全文
posted @ 2023-10-09 08:30 古道轻风 阅读(1720) 评论(0) 推荐(1) 编辑
摘要: 架构演进 大型网站的技术挑战主要来自于庞大的用户,高并发的访问和海量的数据,任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户,问题就会变得很棘手。大型网站架构主要就是解决这类问题。 架构选型是根据当前业务需要来的,在满足业务需求的前提下,既要有足够的扩展性也不能过度设计,每次的架构升级都 阅读全文
posted @ 2023-10-08 08:27 古道轻风 阅读(186) 评论(0) 推荐(0) 编辑
摘要: 一、数据模型架构规范 1.数据层次的划分 ODS:Operational Data Store,操作数据层,在结构上其与源系统的增量或者全量数据基本保持一致。它相当于DW数据的一个数据准备区,同时又承担着基础数据的记录以及历史变化。其主要作用是把基础数据引入到DMP。 CDM:Common Data 阅读全文
posted @ 2023-10-07 08:30 古道轻风 阅读(303) 评论(0) 推荐(0) 编辑
摘要: 1 主从读写分离 大部分互联网业务都是读多写少,因此优先考虑DB如何支撑更高查询数,首先就需要区分读、写流量,这才方便针对读流量单独扩展,即主从读写分离。 若前端流量突增导致从库负载过高,DBA会优先做个从库扩容上去,这样对DB的读流量就会落到多个从库,每个从库的负载就降了下来,然后开发再尽力将流量 阅读全文
posted @ 2023-10-06 08:16 古道轻风 阅读(197) 评论(0) 推荐(0) 编辑
摘要: 软件设计原则 GRASP 通用职责分配软件模式 来自 Craig Larman 的软件设计书《UML 和模式应用》,Larman 在书中提出软件设计的关键任务是职责分配,并提炼总结出 9 种 (5 种核心 +4 种扩展) 软件职责分配模式,这些模式是比 GoF 设计模式更抽象的元模式。 信息专家 ( 阅读全文
posted @ 2023-10-05 12:53 古道轻风 阅读(220) 评论(0) 推荐(0) 编辑
摘要: 1. 为什么要拆分数据库? 单体项目在构建之初,数据库的负载和数据量都不大,所以不需要对数据库做拆分,小型财务系统、文书系统、ERP系统、OA系统,用一个MySQL数据库实例基本就够用了。 就像《淘宝技术这十年》里面说到的,电商业务的数据量增长飞快,所以最开始的PHP+MySQL的架构已经不能满足实 阅读全文
posted @ 2023-10-05 09:34 古道轻风 阅读(124) 评论(0) 推荐(0) 编辑
摘要: 1.背景 H5 页面做秒开优化是业务的常规操作,一般正常通过网络请求的 H5 页面,我们都是围绕资源加载速度优化展开。优化手段主要分两个方向,一个是提升网络速度,一个是减少资源大小。 提升网络速度,一般的手段有 DNS 预解析、多域名、升级 HTTP2、使用 CDN、SSR。而即使有静态资源的网络缓 阅读全文
posted @ 2023-10-04 19:25 古道轻风 阅读(171) 评论(0) 推荐(0) 编辑
摘要: 本文记录了稳定性摸排过程中的一些思考和沉淀。 阅读全文
posted @ 2023-10-04 08:01 古道轻风 阅读(87) 评论(0) 推荐(0) 编辑
摘要: 索引原理 倒排索引 倒排索引(Inverted Index)也叫反向索引,有反向索引必有正向索引。通俗地来讲,正向索引是通过key找value,反向索引则是通过value找key。ES底层在检索时底层使用的就是倒排索引。 索引模型 现有索引和映射如下: { "products" : { "mappi 阅读全文
posted @ 2023-10-03 19:56 古道轻风 阅读(123) 评论(0) 推荐(0) 编辑
摘要: 观察者模式在实际开发过程中是非常常见的一种设计模式。 Spring Event的原理就是观察者模式,只不过有Spring的加持,让我们更加方便的使用这一设计模式。 一、什么是观察者模式 概念: 观察者模式又叫发布-订阅模式。 发布指的是当目标对象的状态改变时,它就向它所有的观察者对象发布状态更改的消 阅读全文
posted @ 2023-10-03 07:55 古道轻风 阅读(126) 评论(0) 推荐(0) 编辑
点击右上角即可分享
微信分享提示