首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

Golang 简洁架构实战

devYun/go-clean-architecture 转载请声明出处哦~,本篇文章发布于luozhiyun的博客:https://www.luozhiyun.com/archives/640 由于golang...不像java一样有一个统一的编码模式,所以我们和其他团队一样,采用了 Go 面向包的设计和架构分层这篇文章介绍的一些理论,然后再结合以往的项目经验来进行分包: ├── cmd/ │ └── main.go...The Clean Architecture 在简洁架构里面对我们的项目提出了几点要求: 独立于框架。该架构不依赖于某些功能丰富的软件库的存在。...对于简洁架构来说分为了四层: Entities:实体 Usecase:表达应用业务规则,对应的是应用层,它封装和实现系统的所有用例; Interface Adapters:这一层的软件基本都是一些适配器...不过这里稍微麻烦了一点,因为我们接入层用的是 gin,所以还需要在单测的时候模拟发送请求; 由于我们是通过 github.com/golang/mock/gomock 来进行 mock ,所以需要执行一下代码生成

1.1K10

Golang整洁架构实践

---- 看目录,点收藏 1.为什么要有代码架构 2.好的代码架构是如何构建的     2.1 整洁架构     2.2 洋葱架构     2.3 六边形架构     2.4 COLA架构 3....推荐一种 Go 代码架构实践 4.总结 *本文提及的架构主要指项目组织的“代码架构”,注意与微服务架构等名词中的服务架构进行区分。...─ config // 配置实现│   ├── database //(可选)内层所需持久化的实现,可以是MySQL,MongoDB,Neo4j等│   ├── distlock //(可选)内层所需分布式锁的实现...数据库操作依赖的数据对象│   │   └── mysql.go // MySQL 实现的数据持久化│   ├── distlock│   │   ├── distributed_lock.go // 分布式锁接口...,在此是因为domain/gateway中没有直接需要此接口│   │   └── redis.go // Redis 实现的分布式锁│   ├── log│   │   └── log.go // 日志封装

1.7K50
您找到你想要的搜索结果了吗?
是的
没有找到

Golang 整洁架构实践

作者:donghli,腾讯 PCG 后台开发工程师 了解过 Hex 六边形架构、Onion 洋葱架构、Clean 整洁架构的同学可以将本篇文章介绍的实践方法与自身项目代码架构对比并互通有无,共同改进。...没了解过上述架构的同学可以学习一种新的架构方法,并尝试将其应用到业务项目中,降低项目维护成本,提高效率。 本文提及的架构主要指项目组织的“代码架构”,注意与微服务架构等名词中的服务架构进行区分。...config // 配置实现 │   ├── database //(可选)内层所需持久化的实现,可以是MySQL,MongoDB,Neo4j等 │   ├── distlock //(可选)内层所需分布式锁的实现...数据库操作依赖的数据对象 │   │   └── mysql.go // MySQL 实现的数据持久化 │   ├── distlock │   │   ├── distributed_lock.go // 分布式锁接口...,在此是因为domain/gateway中没有直接需要此接口 │   │   └── redis.go // Redis 实现的分布式锁 │   ├── log │   │   └── log.go /

72931

Golang分布式限流开源实现

开源实现 uber官方实现 优点:star最高 缺点:功能比较简单,阻塞等待直到获得令牌,不支持分布式,只支持漏桶算法 ulule/limiter 优点:支持把令牌存储到Redis和memory中,还支持不同的...tollbooth 缺点:HTTP服务端限流,也不支持分布式 beefsack/go-rate 优点:阻塞式和非阻塞的都有,实现简单 缺点:不支持分布式 vearne/ratelimit 优点:支持Redis...,并且是非阻塞的 缺点:试了一下有问题,Git上给作者提了issues speedbump 优点:支持Redis 缺点:近四年没有更新 redis_rate 优点:go-redis官方实现,支持分布式,...非阻塞,使用简单 缺点:只支持漏桶算法 经过对开源项目的对比和测试,redis_rate支持分布式,是redis官方实现的,版本也一直再更新 ,使用也很方便。

2K70

初识分布式架构

分布式架构的常见概念 集群 小饭店原来只有一个厨师,切菜洗菜备料炒菜全干。后来客人多了,厨房一个厨师忙不过来,又请了个厨师,两个厨师都能炒一样的菜,这两个厨师的关系是集群。 ?...分布式 为了让厨师专心炒菜,把菜做到极致,又请了个配菜师负责切菜,备菜,备料,厨师和配菜师的关系是分布式,一个配菜师也忙不过来了,又请了个配菜师,两个配菜师关系是集群。 ?...节点 节点是指一个可以独立按照分布式协议完成一组逻辑的程序个体。在具体的项目中,一个节点表示的是一个操作系统上的进程。...在这个过程中,开发模式、技术架构等都会发生非常大的变化。 阶段一,单应用架构 网站的初期也可以认为是互联网发展的早起,我们经常会在单机上跑我们所有的程序和软件。...前期通过这些技术能够很好的解决各个服务之间通信问题,但是互联网的发展是持续的,所以架构的演变和优化还在持续。 架构全局图 ?

96610

分布式系统架构-----异地多活架构

分布式系统架构-----异地多活架构 背景 最近公司在搞异地多活,特来写篇文章来学习和回顾一下。 异地多活看字面意思 :不通的地方部署服务。...这些自然灾害我们是不可避免的所以我们得从架构层面解决这种突发问题。 异地多活架构 1. 什么是异地多活架构? 异地:不同的地理位置,多活:不同的地理位置的服务都能独立提供服务。...但是像这种出现广州地震那么这种情况这种架构仍然解决不了问题的,但是我们结合故障的发生的概率和架构的复杂度之间取一个平衡的话,那对于这种架构来是最优的。...大概服务的物理架构图如下: 从上面架构图可知: mysql 采用主从机制 redis 使用两个集群,通过双写实时同步 quee采用的主备用 job 和 服务就是两个异地集群 遇到的问题 服务数据一致性问题...启动好后数据一致性问题: 因为还有就是数据库mysql的数据是实时在变化的所有这个时候redis的数据和mysql的数据就会有可能不一致,通过架构图可知。

1.2K10

『互联网架构』软件架构-分布式架构(14)

分布式架构:原理,设计与实战,目前公司每个月都要出账,出账就是每个月有要把之前的一个月的账目盘算清楚,做到错误的0容忍,一笔都不能错,错一笔客户都会找你,偏准确性。...分布式服务的发展历程 J2EE架构 俗称JEE。对于大概有5年以上工作经验的老铁,应该都听过这个名词。基本分为3层。...微服务架构 最流行的架构,跟传统架构是一脉相承的,并不是矛盾的。采用的是分层的概念,上层的服务依赖下层的服务,基本两层,第一层:业务服务一;第二层:业务服务2,3,4。...分布式服务架构的精髓 敏捷上线,微服务下的自治,有效的减少不可用的因素。服务化和微服务都使用了分而治之的思想,分布式服务和分布式系统架构里面,无论是提高性能,提高吞吐量,提高敏捷性。 ?...开关要能开能关 迁移开关要大小力度都有 PS:了解分布式架构,是对自己从心智上的一种提升,敲代码只是往下看,建议多往前方看看。架构这条路不好走,需要多接触,多趟多走,才能前方一路小平破。

1K20

分布式架构 Broker 简介

概述 随着业务规模和复杂性的不断增长,分布式计算成为了数据持久化、运算高性能的必要选择,然而,分布式多机器、多集群的协作成为了一个问题,如何让规模巨大的多机器甚至多个集群协同工作呢?...解决问题的方法就是抽象化的分布式架构,通过代理的方式让客户端与服务端解耦,使各种突发事件能够被透明化的解决,同时,服务的调用者期望服务对他而言足够简单,最好是像调用本地服务一样简单,各种分布式架构应运而生...同时,由于模块化、抽象化,让整个架构各组件之间耦合度很低,Server 注册即可用,大大增加了可伸缩性、可维护性,动态扩展变得简单而高效。 3.2....缺点 显而易见的,整套架构的复杂度很高,在实际的生产环境中,Broker 怎么及时发现意外断开的 Server,如何实现负载均衡都是需要考虑的问题。...这样的搞复杂度让整个架构过于庞大,除非分布式计算任务太过复杂,通常使用者都会对这个架构做出不同程度的简化,比如 Client、Server 公用一个或多个 Broker、去除 Bridge、统一跨平台通信协议等

1.5K20

java分布式分布式架构)「建议收藏」

开头的话,架构多半和业务关联在一起,如果只是简单的图书管理系统、选课系统或者什么简单的财务系统,用不着分布式。只有大型公司、高并发的业务才需要分布式的帮助。...当然,架构本身要和业务模型紧密配合才能发挥作用。 很长一段时间,java都是最流行的编程语言。...业务量的激增、用户的需求,导致整个软件的架构一直在改变。好的软件架构不光可以满足当前的业务需要,而且为未来的扩展打下基础。...从软件架构来说,java和分布式这个主题,可以给大家带来很多积极和有益的思考。 说到架构,或者软件框架,这个和os没有关系,和编译器、编程语言没有多大关系。...分布式架构里面有成功、失败、超时三个情况,而超时就是最大的问题。所以,如何处理这个超时问题才是重中之重。当然,很多朋友都听过cap理论,也就是高可用性、性能、一致性,一般只能三者取其二。

2.3K20

聊聊分布式系统架构

去中心化:全球IP互联网就是一个典型的去中心化的分布式控制架构,联网的任意设备宕机都只会影响很小范围的功能。去中心化设计通常没有“领导”和“干活的”,角色一样,地位平等,因此不存在单点故障。...实际上,完全意义的去中心化分布式系统并不多见,很多看起来是去中心化但工作机制采用了中心化设计思想的分布式系统正在不断涌现,在这种架构下,集群中的领导是动态选择出来的,而不是人为预先指定的,而且在集群发生故障的情况下...二、分布式系统架构的主要内容 分布式系统架构的主要内容包括: RPC和对象序列化 分布式内存缓存技术、分布式内存计算 分布式存储 分布式计算 全文检索 消息队列 容器 1、RPC和对象序列化 RPC设计的初衷是设计一套远程通信的通用框架...服务注册、服务发现和服务监控后来成为通用分布式系统架构的核心和关键技术基础,也被赋予一个新概念--“服务治理框架”,最早的说法可能来自BAT的一些架构师。...如果一个分布式系统具备如下特点,则可以称之为“微服务架构”:1、任何一个服务都由多个独立的进程提供服务,这些进程可以分布在多台物理机上,任何进程宕机都不会影响系统提供服务;2、整个系统是由多个微服务有机组成的一个分布式系统

1.2K30

分布式架构之美

一、前言 我们都知道,当今无论在BAT这样的大公司,还是各种各样的小公司,甚至是传统行业刚转互联网的企业都开始使用分布式架构,那么什么叫分布式架构呢?分布式架构有什么好处呢?...分布式架构经过了怎样的发展呢?是哪家企业开启了分布式架构的时代呢?读完本文,你就会得到这些答案,下面让我们一起来开启分布式概述的奇妙之旅吧!...四、分布式系统的意义 之所以要发展分布式系统架构,是因为单机系统存在着如下诸多缺点等待被解决: 升级单机处理能力的性价比越来越低 我们知道单机的处理能力主要依靠 CPU、内存、磁盘。...五、分布式架构的常见概念 1.集群 小张开了一家小饭店,刚开始的时候店里只有一个厨师,切菜洗菜备料炒菜全干。...三态 在集中式架构中,调用一个接口返回的结果只有两种, 成功或失败。但是在分布式架构中,会出现“超时”这个状态。

69940

分布式服务架构(二)

,否则难以支持亿级流量,即使关系型数据库,单机也难以支持存储和吞吐量的性能需求,如果必须要这样做,就应尽量把数据放到数据库一个分片上,这样就可以利用数据库解决不一致的问题, CAP C:一致性,在分布式系统中...将相关的数据分到数据库的同一个分区,任然可以解决数据一致性问题 由于业务限制,并不能将数据放到一个数据库分片,因此我们记录事务的软状态,如果出现不一致,就可以通过系统自动化或者人工干预修复不一致的问题 分布式一致性协议...在分布式系统中构建了唯一的id,调用链的等基础设施后,我们可以很容易对系统间的不一致进行核对,通常需要第三方的定时核对系统,从第三方监控服务执行的健康程度....5.可靠消息模式 在分布式系统中,我们经常使用的就是上面提到的异步确认模式,为了让一步操作的调用方和被调用方充分的解耦,采用消息队列,具有可以伸缩性,可分片,可持久化等, 消息的可靠发送 消息的可靠发送认为是尽最大努力发送消息通知

66420

什么是分布式架构?

其部署简单,不用考虑多个节点间的分布式协作问题。 三、分布式系统 分布式系统是一个由硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。...3.3 并发性 同一分布式系统中的多个节点,可能会并发地操作一些共享资源,诸如数据库或分布式存储等,如何高效地协调分布式并发操作也成为了分布式系统架构与设计中最大的挑战之一。...5.2 分布式事务 分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上,通常一个分布式事务中会涉及对多个数据源或业务系统的操作。...一个分布式事务可以看做是由多个分布式的操作序列组成,通常可以把这一系列分布式的操作序列称为子事务。...由于在分布式事务中,各个子事务的执行是分布式的,因此要实现一种能够保证ACID特性的分布式事务处理系统就显得格外复杂。

5.5K31

再谈分布式服务架构

在两年前,我曾经设计过一版,高可伸缩服务器架构, 但只进行了理论推演,并没有使用具体业务逻辑验证过。以这两年的经验来看,这个架构不具备可实施性。 在之前的架构中,我只考虑了Gate和其服务之间的交互。...分布式情况下ACID的难度要远高于单机ACID, 而且性能也得不到保证。这也是为什么后来会有很多NOSQL的出现。NOSQL其实更应该叫NO ACID才对。...然而,由于现代分布式数据库领域都还没有特别完美的ACID解决方案。我们的游戏服务之间的交互更不可能提供ACID功能了。 幸运的是,这个世界是平衡的。...我认为在游戏服务器的分布式领域中,我们只要阻止错误的发生就可以了。至于异常是避免不了的(比如超时)。 基于这个原则和我两年前的架构设计,我重新抽象了整个分布式架构。...这次的抽象和上次一样,我并不企图抹平分布式的事实,仅仅只是为了抹平同一个服务会被水平布署多份的事实。 ---- 在设计完这个抽象之后,一个自然而然的事实,摆在我面前。 假如,有三个服务A,B,C。

39030
领券