Utopian

Temporalio 简介简介引用wiki来介绍工作流引擎的定义： A workflow engine manages and monitors the state of activities in a workflow, such as the processing and approval of a loan application form, and determines which new activity to transition to according to defined processes (workflows). The actions may be anything from saving an application form in a document management system to sending a reminder e-mail to users or escalating overdue items to management. A workflow engine facilitates the flow of information, ...

简介go-clean-template是一个golang的微服务模板，按照Robert Martin《代码整洁之道》的各原则来实现。业务方可以使用该模板来扩展构建自己的微服务。 提供的能力项包括： 按照DIP、ISP等原则来组织框架层、业务逻辑层以及数据层等代码实现。 配置文件解析，包括端口号、日志、PG等RabbitMQ配置。 集成gin框架，提供了几个HTTP接口demo实现。 集成了RabbitMQ RPC，提供了1个接口的demo实现。 集成了日志、Swagger、K8s probe、Prometheus上报等能力。 本项目主要是作为模板来演示如何构建可扩展、易于维护的微服务，因此在实现上比较简单，业务方可以根据实际需求进一步改造扩充。 工程架构 启动方式 README中给出了docker的构建方式,也可以将相关代码copy出来之后自行go build构建。 注意服务依赖RabbitMQ、PostgreSQL，启动前需要搭建对应的容器或者实例。 目录结构 cmd: cmd处理逻辑。 config：配置解析 docker-compose.yml： Image构 ...

背景之前在网上找了不少存储图片的地儿，貌似都不是很靠谱。也研究了一下腾讯云，似乎也没有提供直接可用的图片存储服务。看网上的经验有人使用腾讯云cos+cdn直接搭建了一个个人的图片存储服务，感觉流程也挺简单，于是研究后操作了一番，发现也有不少弯路，于是记录一番。 cos基础对象存储COS为腾讯云提供的云存储服务，可以简单的理解为云硬盘，可以通过页面、接口上传文件到特定的目录(实为bucket)。具体流程就不介绍了，参考官方文档。 创建bucket之后，每个bucket会有一个独立的访问域名，可以通过http域名直接访问文件。注意需要先将存储桶访问权限改为”公有读私有写“。 这样一个简单的文件上传、下载服务器就搭建好了。可以直接在文件列表中上传、下载文件以及管理工作。 优化上传通过页面上传肯定不是一个好的方案，上传每次都要通过腾讯云页面操作，成本太高。 Mac下有个很方便的工具uPic，可以方便的上传到cos。可以直接从git release下载，应用市场也提供了收费版本。uPic支持多种图床用作存储服务，包括腾讯云cos。我用的git免费版本，cos图床配置大致如下： 注意点： ...

最近阅读量大量关于秒杀系统的介绍文章，包括一些视频讲解，大部分文章都太冗长，没有触及核心设计点，本文主要总结下后台架构的核心设计要点，不讨论架构优化中的常规页面CDN化、隔离部署、数据sharding、缓存优化等常规手段。 背景秒杀系统场景举例： 抢购：如双十一，下单量高峰能达到50w+ qps，注意是下单成功，同时参与抢购的人的那就更多一个数量级了。 红包：直播间红包、微信红包，本质上都是类似的场景，微信红包的处理方案是提前对红包进行个数拆分，会简化扣除库存逻辑，但是本质上跟抢购类似。 此类系统有几个典型特点： qps高，tps低：即读多写少，大量的请求（包括非正常请求：如频繁重试、黑产请求等）但是只有少量能成交。 库存需要精确：涉及金额，不允许超卖 固定时间：活动时间通常通常很短 其中超卖问题为核心需求点，基于此衍生出如何抗住并发量、用户体验优化等解决方案。 简单方案先考虑一个简单的实现方案，然后基于此方案的问题进行优化。 存储模型以DB为例，考虑拆分如下几个表： 秒杀活动信息表： 用于新建秒杀活动，包括活动信息、时间段、秒杀商品等 商品表：存储商品详细信息 库存表s ...

《微服务实战》读书笔记 微服务的定义三大关键特性 每个微服务只负责一个功能 每个微服务都有自己的数据存储 // 低耦合，只能通过接口访问对方数据 微服务自己负责编排和协作 // 高内聚？ 两个基本特性 可独立部署 // 非庞大的单体应用 可替代 微服务架构原则 自治性：松耦合，可独立部署 可恢复性：故障隔离，模块故障仅影响微服务自身。 // 是不是叫“隔离”更加合适 透明性：每个微服务有完整的日志、监控以及基础设施数据 自动化：保障系统频繁部署和运维的正确性，通过引入流水线or云函数 一致性：微服务需要考虑向后兼容，确保不需要强迫其他团队升级或者破坏服务之间的复杂交互。 为何选择微服务 技术差异性：允许根据服务的特性选择不同的技术栈 系统复杂度会逐步增加：不断缩短的交付周期 降低重复和风险：灵活性、部署风险 微服务的设计、运维挑战 划定微服务范围需要领域知识：如何划分某个服务的职责需要对领域有充分的理解。 良好的契约设计 // 多团队设计，需要服 ...

最近在阅读微服务相关书籍时，提到了微服务相关的监控措施，其中分布式追踪就属于其中不可或缺的一部分，恰好之前也有计划在团队内引入，所以就花了两天时间稍微深入了解了一下相关概念和实现。动手实验了一遍jaeger提供All-In-One+HotROD示例，也大致了解了其基本原理和实现思路。时间关系就没有去学习jaeger之类的系统源码了，深入了解其存储方案之类的细节了，感觉必要性不大。 为什么需要Tracing微服务在部署上线后，需要有一套完善的监控体系来监控服务的质量。可观察性就是更关注的是从系统自身出发，去展现系统的运行状况，为开发运营人员提供故障排查、维护及优化的相关信息。 可观察性目前主要包含以下三大支柱： 日志（Logging）：Logging 主要记录一些离散的事件，应用往往通过将定义好格式的日志信息输出到文件，然后用日志收集程序收集起来用于分析和聚合。虽然可以用时间将所有日志点事件串联起来，但是却很难展示完整的调用关系路径； 度量（Metrics）：Metric 往往是一些聚合的信息，相比 Logging 丧失了一些具体信息，但是占用的空间要比完整日志小的多，可以用于监控 ...

整理下目前业务已有的监控能力以及相关指标、维度。大部分开发关注的可能只是自身服务的质量，缺乏对整体链条监控的了解。业务的发展过程中，出现过太多非后端服务质量导致的异常，所以要求开发能对服务整体的监控能力有所了解。 后台逻辑服务层后端逻辑服务，目前主要基于123+007平台。 【下游】trpc主调 指标：请求量、耗时、失败率（区分超时、异常） 维度：（下游）服务-接口、ip、返回码 【自身】trpc被调 指标：请求量、耗时、失败率（区分超时、异常） 维度：（本服务）服务名-接口、ip、返回码 【自身】trpc属性监控 指标：业务自定义指标，包括trpc框架自动上报性能指标，如goroutine数、node event loop lag等。 维度：可按单机展开 【自身】容器负载 指标：cpu、内存、磁盘、带宽 维度：可按单机展开 总结 优势：对下游监控完善，容器负载监控可以覆盖自身大部分异常 不足：服务内部异常（如内部block导致出现服务毛刺等）依赖业务自身上报【自身异常也可以通过上游发现】 业务接入层实现取决于业务团队能力，小团队一般直接用nginx ...

Written with StackEdit. Reliable Cron across the Planet…or How I stopped worrying and learned to love time Štěpán Davidovič, Kavita Guliani, Google 原文: https://queue.acm.org/detail.cfm?id=2745840 前段时间预研分布式任务调度系统的方案，了解到了一个比较靠谱的解决方案：dkron，看介绍其实现就是基于基于google的这篇whitepaper 《Reliable Cron across the Planet》。 这篇文章也被收录到了书籍《SRE：google运维解密》一书中（第24章），于是将部分内容摘抄了一遍，补充了部分自己的理解，当做自己的读书笔记了。文章较长，部分个人认为不重要的内容就简单跳过了。 本文主要介绍了google的cron调度服务的实现机制，重点对实现的难点部分做了详细介绍。详见下文。 先对Cron系统的功能做了个简单的介绍。包括单机下crontab格式以及linux下的cr ...

libuv源码简介习惯了思维图之类的简单整理之后，有一段时间没有认真写写东西了。前段时间为了研究下node的性能指标，特意复习了一下libuv的源码，但是一直懒得去整理，直到今天看到这段话后才决定整理一番： 学习是一种行动反射，不是为了晓得些『知识』，要切己体察，代入自己要事上琢磨，落实行动，这就是知行合一。否则，读书也是一种玩物尚志。 定期总结也是学习的一部分。 简介 libuv是个异步服务的框架，整体实现及功能先看一下libuv官网的这张分层结构图。 底层根据操作系统类型，选择不同的多路复用实现。linux下基本就是epoll了。据说nodejs选择libuv而非libev作为底层实现，是因为libuv等windows的支持更为友好（IOCP）。具体没有对比详细对比过。 uv__io_t：从底层看，上层大部分的操作都跟io有关，或者可以转换为io操作。如tcp/udp的网络IO，tty的相应，signal的处理、pipe读写等。所以libuv封装了一层IO“基类”，工其他handler使用。 Handler：TCP、UDP、Pipe等，定位类似libeven ...

memberlist实现分析gossip简介Gossip protocol 也叫 Epidemic Protocol （流行病协议），实际上它还有很多别名，比如：“流言算法”、“疫情传播算法”等。这个协议的作用就像其名字表示的意思一样，非常容易理解，它的方式其实在我们日常生活中也很常见，比如电脑病毒的传播，森林大火，细胞扩散等等。 Gossip的基本思想一个节点想要分享一些信息给网络中的其他的一些节点。于是，它周期性的随机选择一些节点，并把信息传递给这些节点。这些收到信息的节点接下来会做同样的事情，即把这些信息传递给其他一些随机选择的节点。一般而言，信息会周期性的传递给N个目标节点，而不只是一个。这个N被称为fan-out（扇出）。 数据一致性问题的背景&目标问题： 如何在多网络中将多个节点实现并保持数据一致性。 能够随着节点数量的增加而优雅地扩展。 考量的因素： 单节点信息变更后，更新传播到所有其他节点所需的时间 传播单个更新时生成的网络流量 机制在《Epidemic Algorithms for Replicated Database Maintenance》论 ...