架构设计
mask哥
工匠精神coding,终生学习
展开
-
elasticsearch集成springboot详细使用
详解springboot集成elasticsearch常见操作使用原创 2024-08-10 15:28:59 · 1089 阅读 · 1 评论 -
DP-适配器模式代码重新理解
【代码】DP-适配器模式代码重新理解。原创 2024-07-19 20:52:02 · 296 阅读 · 1 评论 -
微服务架构设计关键点总结
微服务架构设计要点详细总结以及NFRS(非功能性需求)补充。原创 2024-06-26 13:27:50 · 182 阅读 · 0 评论 -
领域驱动设计(DDD)&微服务架构模式总结
领域驱动设计&微服务架构模式原创 2024-06-21 12:07:29 · 848 阅读 · 0 评论 -
微服务中4种应对跨库Join的思路
在很多场景下,我们字段的依赖是很多的,乃至查询的时候可能需要跨多张表,这个时候方法1就无法直接用了,我们就需要进行表级别的数据同步,可以采用ETL工具来做到跨库的表同步。A库中的Tab1表需要关联B库中的Tab2表中的字段F, 我们就将字段F冗余到表Tab1中,那么查询时候,Tab1和Tab2就不需要做Join,单独查A库中的Tab1表就可以解决问题。以上就是4种应对跨库Join的思路,实战中,一定是将这4类方案进行组合使用的,同时,需要注意的是,相比这些解决思路,更重要的是表结构的合理设计。原创 2024-02-19 14:06:31 · 867 阅读 · 0 评论 -
工资计算系统设计实现
part1XX 公司有三种类型的雇工, 不同类型的员工有不同的工资计算方式, 具体薪资计算规则如下。• 小时工,每小时薪资为 40 元。• 经理,每小时薪资为 60 元,每月工作满 150 小时就可以得到全额工资 10000 元。如果工作不满 150 小时,则按照 实际工作时间和时薪计算工资• 销售人员, 基础工资为每月 3000,每月基础销售额应为 20000,如果销售额为 20000-30000,则超出部分(超出 20000 部分)提成率为 5%,如果销售额为 30000 及以上,则超出原创 2022-04-08 18:55:36 · 2387 阅读 · 0 评论 -
dubbo3.0新特性总结
dubbo3.0的变化: 1.服务发现模型: 2.0采用基于接口粒度的服务发现机制,3.0基于应用粒度的服务发现机制,有利于提高系统资源利用率,降低 Dubbo 地址的单机内存消耗(50%),降低注册中心集群的存储与推送压力(90%), Dubbo 可支持集群规模步入百万实例层次; 打通与其他异构微服务体系的地址互发现障碍。新模型使得 Dubbo3 能实现与异构微服务体系如Spring Cloud、Kubernetes Service、gRPC 等,在...原创 2022-03-23 15:34:18 · 4109 阅读 · 0 评论 -
数据中台建设方法
分主题域管理 命名规范定义:表的名称需携带表的主题域、业务过程、分层以及分区信息;构建全局的指标字典。 数据中台采用分层的设计方法,常见的分层模型如下: 指标一致 数据模型复用 数据完善 #构建统一的数据规范标准; #数据即服务,数据中台中数据是通过API接口的方法访问;提高数据共享能力,让数据被用好; 元数据: 数据中台技术体系: HADOOP HDFS:分布式文件系统 YARN/K8S:资源调度系统 SPARK/FLINK:计算引擎 ...原创 2021-10-28 13:51:54 · 988 阅读 · 0 评论 -
需求转换为设计过程关键点
需求场景化,场景角色系统设计化。 功能分主次,核心功能要优先,非功能性需求(性能、安全、风控等)思维要收敛。 需求分析过程经典:《分析模式》、《需求分析》、Martinflower《实现模式》 面向对象术语方法论:solid设计原则、oop、ood、接口、封装、继承、多态(重写、重载)、实现、设计模式以及企业级设计模式。 面向对象设计方法-UML(usecase/状态图/时序图/类图/构件图) 系统设计经典:《微服务设计》、《领域驱动设计》 微服务系统设计应遵循康威定律(参考https://ww原创 2021-08-07 13:24:26 · 454 阅读 · 0 评论 -
架构技术选型考量因素
技术社区活用度与文档完备性 是否经过大量的一线大厂商用与落地验证 技术组件与其配套的成熟度 技术组件底层实现模型与安全 产品核心业务场景的特点 投入资源、成本、时间的平衡原创 2021-07-29 23:14:19 · 472 阅读 · 0 评论 -
系统架构常用的优化手段
静态化:动态数据和静态数据分离 异步化:使用异步化减少主流程中的非关键业务逻辑 并行化:使用多线程并发处理,缩短响应时间 内存优化:减少对象大小,减少对象创造,数据模型优化 去重复运算:业务逻辑优化,或使用缓存 减少数据库操作:数据冗余,数据缓存 缩短数据库事务:短事务,异步化,最终一致性等方式可以考虑 精简代码逻辑:去冗余代码,诸如过度设计检查等代码 精简日志操作:日志大小要关注,注意IO上的瓶颈;日志太多,说明生成的String也会多,也增加了gc的负担...原创 2021-07-28 14:15:59 · 1245 阅读 · 0 评论 -
Redis最佳实践经验总结
原创 2021-07-27 10:31:26 · 198 阅读 · 0 评论 -
mongodb最佳实践经验总结
原创 2021-07-26 22:00:17 · 359 阅读 · 0 评论 -
最全架构设计实践方法论: 微服务
文章目录微服务优缺点 负载均衡 服务调用 熔断 网关 配置中心nacos 安全架构 Auth2.0授权认证 jwt安全认证 访问限流一、微服务优缺点1.优点: 高可用 水平扩展 硬件配置低 业务简单 耦合性低 快速响应 支撑异构 分布式 业务内聚 2.缺点:...原创 2021-07-02 18:50:14 · 246 阅读 · 1 评论 -
SAAS软件的成熟度模型总结
根据是否具有可配置性、高性能、可伸缩可将SaaS成熟度分为四级,每一级都比前一级增加三种特性中的一种。Level1:定制开发为用户提供专用的数据库实例及应用服务器实例,依据用户实际需求进行定制化开发,最初的SaaS应用成熟度模型,在技术架构上和传统项目型软件开发或软件外包没什么区别.有一个客户项目,就按照客户的需求来定制一个版本,每个客户都有一份独立的代码,各版本间可通用的只有少量可重用软件,库及开发人员经验。虽然最初级的SaaS模型,在应用架构上和传统软件模式并没有什么区别,但,在商业模式上,原创 2021-06-30 11:22:28 · 455 阅读 · 0 评论 -
架构师知识体系全景图
知识体系:知识体系可以分为几个层次:个人能力层,外包能力层,解决方案能力层,咨询能力层。从个人成长角度看会从底层能力成长上层能力。从企业方面,使用企业规划、实施方法去自上而下的完成。从整体上讲有了知识体系之后可以组织自己的知识,并得知自己的欠缺。既可以解决问题,还可以指导学习。以整体的企业架构(EA)为主组合运营、咨询、《软件工程》中的内容形成整套的架构师知识体系。企业架构主要帮助架构师解决项目从哪里来,怎么来,怎么规划的问题。运营,咨询帮助进行辅助的工作支持。再辅以《软件工程》从需原创 2021-06-30 07:51:24 · 1074 阅读 · 0 评论 -
memcache主从数据同步( 安装repcached插件)
1.下载http://sourceforge.net/projects/repcached/files/latest/download?source=files下载插件2.上传下载tar包到usr/local/目录,解压 tar -zxvf memcached-1.2.8-repcached-2.2.1.tar.gz3.编译 进入cd memcached-repcached/目录 编译执行./configure --enable-replication --program-tr...原创 2021-06-29 10:31:01 · 266 阅读 · 0 评论 -
中台战略的本质
构建大中台,小前台组织机制和业务机制,敏捷快速适应市场变化 中台集合一个公司的运营数据能力、产品技术能力,对各前台业务形成强力支撑 提倡:厚平台,薄应用架构模式 共享服务中心的架构目的是通过业务拆分降低系统的复杂性;通过服务共享提供可重用行;通过服务化来支持业务的敏捷性;通过统一的数据架构来消除数据交换的屏障; 共享服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元 共享服务的目标是把普通的服务能力升级为组件化的服务并提供良好的治理能力...原创 2021-06-17 19:49:03 · 274 阅读 · 0 评论 -
浅谈六边形架构
定义:六边形架构又称作端口和适配器模式,是一直对称性的架构风格;系统通过适配器的方式与外部交互,将应用服务于领域服务封装在系统内部;也是一种分层架构(主要分为:端口适配器、应用层:定义系统可以完成的工作、领域层:负责表示业务概念、规则与状态)...原创 2021-06-17 16:40:11 · 763 阅读 · 1 评论 -
数据模型与业务模型(领域模型)的区别
1.数据模型(Data model);指业务数据该如何持久化,以及数据之间的关系,即:传统的ER模型;数据模型存在于数据层。2.业务模型(领域模型:Domain model):指业务逻辑中,相关联的数据如何联动协同;领域模型存在于领域层;衔接数据层与领域层的关键对象是Repository(DAO);Entity(实体对象):实体对象是我们正常业务应该用的业务模型,它的字段和方法应 该和业务语言保持一致,和持久化方式无关;。Entity 的生命周期仅存在于内存中, 不需要可序列化和可持久化..原创 2021-05-17 16:35:42 · 4136 阅读 · 1 评论 -
一线架构师具备的软技能
原创 2021-05-10 15:29:17 · 102 阅读 · 0 评论 -
最全架构设计实践方法论(三)
1.架构思维2.架构能力3.架构方法从0到1的过程抓大目标,从1到N的过程抓细节;技术变化的过程是:如何让各个领域内减少协同(分而治之);4.领域建模方法原创 2021-05-08 11:48:53 · 150 阅读 · 0 评论 -
分库分表遵循的原则
原则一:能不分就不分,1000 万以内的表,不建议分片,通过合适的索引,读写分离等方式,可以很好的解决性能问题。原则二:分片数量尽量少,分片尽量均匀分布在多个 DataHost 上,因为一个查询 SQL 跨分片越多,则总体性能越差,虽然要好于所有数据在一个分片的结果,只在必要的时候进行扩容,增加分片数量。原则三:分片规则需要慎重选择,分片规则的选择,需要考虑数据的增长模式,数据的访问模式,分片关联性问题,以及分片扩容问题,最近的分片策略为范围分片、枚举分片、一致性 Hash分片,这几种分片都有利于扩容。原创 2021-05-08 11:11:50 · 1770 阅读 · 0 评论 -
(九)架构方法论-技术架构:常用开源中间件
批量任务:elastic-job/xxl-job链路追踪:skywalking配置中心:nacos/apollo网关:soul/gateway注册中心:zk/etcd/eureka/nacos分库分表:mycat数据库访问层: sharding-jdbc文件存储:fastdfs/阿里oss数据库同步组件:cannal分布式事务:EVENTSOURCE+可靠消息(rocketmq/rabbitmq) 、seata消息中间件:kafka/rocketmq/rabbitmq...原创 2021-05-08 10:58:37 · 188 阅读 · 1 评论 -
理解分布式CAP原理
1.CAP:一致性(Consistency)、可用性(Availability)、分区容忍性(Partition tolerance)。2.CAP 原则指三个要素最多只能同时实现两点,不可能三者兼顾。3.注册中心原创 2021-05-08 10:50:27 · 124 阅读 · 0 评论 -
最全架构设计实践方法论(二)
最全架构设计实践方法论:技术架构微服务技术 1.设设计原则: 分层原则:上层服务可调用下层服务,下层服务不可调用上层服务,只能通过MQ通知上层服务一些事件发生 分组原则:紧密相关的服务构成一组,组内所有服务通过一个API网关暴露服务 单一原则:外部服务只能通过gateway调用组内服务 服务自治理原则 轻量级通讯原则 接口明确原则 敏捷开发 ...原创 2021-03-16 11:52:01 · 640 阅读 · 1 评论 -
最全架构设计实践方法论(一)
架构设计方法原创 2021-03-15 15:04:46 · 2537 阅读 · 3 评论 -
微服务网关soul搭建
1.git clonehttps://github.com/Dromara/soul.git源码2.安装zk3.刷入 源码目录scripts/下soul.sql到数据库4.修改soul-admin目录下相关参数5.启动SoulAdminApplication ,访问http://localhost:8888/index.html输入 admin /1234566...原创 2019-07-04 23:05:35 · 5850 阅读 · 1 评论 -
使用dubbo做微服务网关的选型
kong luna语言 orange soul java语言 (个人比较推荐的,因为底层基于netty filterchain,可插件是开启网关依赖插件,参照了kong和springcloud gateway实现的理解,并且提供了网关的功能治理) waf littleproxy zuul gateway 最终推荐使用Dubbo+s...原创 2019-06-29 00:21:34 · 6737 阅读 · 2 评论 -
微服务应用的十二个因素
1 - Codebase一份基准代码,多份部署Twelve-Factor App为每个应用推荐一个代码库。在微服务架构中,正确的方法实际上是每个服务的一个代码库。此外,我们强烈建议使用Git作为存储库,因为它具有丰富的功能集和巨大的生态系统。GitHub已经成为开源社区的默认Git托管平台,但根据贵组织的需求,还有许多其他优秀的Git托管选项。2 - 依赖关系显式声明依赖关系正如The ...原创 2019-06-29 00:13:50 · 632 阅读 · 0 评论 -
Instagram的技术架构
Instagram 被 Facebook 以10亿美金收购。团队规模:13 人。而在被Facebook收购前的一个月,整个团队才7名员工。2010年: 2位工程师2011年: 3 位工程师2012年: 5 位工程师制胜法宝:广泛的单元测试和功能测试坚持DRY(Don’t Repeat Yourself)原则使用通知/信号机制实现解耦我们大部分工作转载 2014-08-12 13:47:47 · 1259 阅读 · 0 评论