fwhezfwhez的博客

前言对服务进行拆微的过程中，有以下问题需要考虑:拆离前后，旧服务要继续保持可用性。不能出现通知业务下游全体修改调用方式。拆离前后，代码低耦合。不能出现业务代码侵入。拆离过程，可以按照【单个接口】【某组接口】进行分块拆离。拆离过程可复制，简单，可复用.最后，整个拆离过程，需要结合团队正在使用中的框架，进行综合考量。本次方案的执行背景是，对 xxxapisrv内的业务服务，抽离出 leafsrv, 原xxxapisrv成为proxy。团队语言是go，框架为gin期望效果接入前r.POS

前言从自建数据库到云数据库的无损迁移方案的设计和实行，是基于以下背景:在服务流量比较少时，多个模块共服务，共数据库。qps起来后，发现数据库因为热点流量，出现了读写瓶颈。在迁移时，数据库选型为自建还是云数据库。因为运维能力在dba层面比较薄弱，暂时不考虑继续维护数据库生态，而使用云厂商的云数据库组件维护，而旧数据源是使用了自建数据库。并且，云数据库不开放定制化双写设置，内部的迁移计划粒度，也无法细化到某个表，并且做不到业务无损。迁移过程，业务方期望用户无感，流量无损，不接受停机。PS: 方案数

前言目前，golang官方的sync.WaitGroup，只有同步作用，缺少了对子任务执行的结果上下文信息。特此，设计了高仿sdk wgx，目前已投入线上使用介绍wgx 是对sync.WaitGroup的增强版，解决sync.WaitGroup的以下问题:sync.WaitGroup只确保子任务被执行，无法传递任务最终的执行结果。wgx支持三个执行结果[全失败，全成功，半失败半成功]。sync.WaitGroup不关注子任务的上下文细节，也不关注失败和成功的计数。wgx支持对失败的任务，进行上

前言当前服务节点集群化架构，一个应用在发布期内，存在多个节点, 发布过程持续过久(30分钟以上)。发布新版需要发布30分钟，基于tag回滚也需要这么长时间。这个在试错上的成本非常大。核心的问题在于，发版前的服务，和发版后的服务，不能共存。引入【灰度服务器集群】, 将【正式服务回滚部署】优化成【旧服务流量切换】。该方式和原方式相比，差异在:新旧服务共存。验收通过以前，只有灰度是基于新tag发布，正式服一直是旧tag。流量切换没有时间开销。回滚部署，要部署很久。如果可以发布前的节点，和发布后的节

前言跨域问题在前后端对接十分普遍。之所以立为解决方案，是因为历史原本的解决跨域的问题，没有效果。实现import "github.com/gin-contrib/cors"func AllowAll() gin.HandlerFunc{ cfg := cors.Config{ AllowMethods: []string{"*"}, AllowHeaders: []string{"*"}, AllowCredentials: false, MaxAge:

前言本文，不对git基本命令作描述。适合群体是1年以上的it从业人员。Git-flow 是git工作流，维护了不同团队在git上的工作流。目前，Git管理，有以下问题:git-flow的样式过多，官方没有约束好，主流推荐的flow方式，导致不同团队git-flow，群魔乱舞，各自有各自的用法。(实际上，它应该有一个最优的flow，作为官方推广。)搜索团队git管理，用法。匹配到的搜索结果，全是基本命令，答非所问，不是一个git管理者想要搜到的东西。本文，从应用场景的角度，对当今git最常见的问

前言跑马灯，是一个比较典型的业务场景。最常见的样式如:恭喜玩家[爱唱歌的李三]在[迎新杯]中，荣获第一名，获得奖励钻石*200, 现金*4元在设计和实现过程中，我们需要考虑以下问题:如何保证每个人都能拉到结果。(定期拉取还是广播推送)如何保证每个人拉取到的结果，不会重复。(如何保存用户已经观看过的记录)跑马灯如何防止无限积压，导致拉取过大。以及复用性问题。为什么要单独把这个需求，当作是解决方案来归档。因为这个场景，确实很容易被开发人员做得很烂。分析取我见到过的解决形式来分析。

前言基于某些场景，我们需要对项目内redis操作，进行切面操作，他包括但不限于:高频同key熔断，防止组员死循环写蹦redis集群。错误收集，对conn.Do("set","uname","tommy","a wrong arg")类回避错误的写法，能够收集到错误信息。统计实时redis流量总之，在某些时候，我们需要对redis操作，进行切面化运作。在实现这种场景时，我们必须保障:不侵入或极少侵入业务代码。拓展灵活。声明本次的解决方案，仅解决golang下github.com/ga

前言Golang在错误处理上，没有形成良好的规范，导致真正用好的人非常少，大部分golang开发人员(哪怕是3年+)在错误处理上，依旧无法避免以下问题:1.单条错误链路过长。err.Elem("用户模块").Text("用户查询信息异常").Stack(debug.Stack()).Attach(map[string]interface{}{ "url": c.FullPath(), "param": param, })2.同种错误，多次处理。control/login

111

前言golang在对接话费充值这一块时，一定会选择同时接入多个渠道。这是基于以下原因:有的渠道便宜，有的渠道很贵。有的渠道对移动/联通/电信手机，不支持，或存在极大的失败率。渠道的不可靠性，需要我们同时接入多个渠道。接入多个渠道，预先定好谁先谁后，然后写充值和回调逻辑，不是很简单吗，为什么特意形成解决方案?这是因为:我们接入新的渠道时，不应该侵入历史接入的渠道业务代码。以前接入渠道的人，可能离职转岗，总之做了交接。充值渠道的价格浮动，可靠性浮动，可能需要变更优先顺序，这个变更操作不应

介绍HTTP服务框架，简单易用。简称类型含义rgin.IRouter路由器对象。c*gin.Context请求上下文。paramParam路由handler的入参绑定对象1. helloworldpackage mainimport( "github.com/gin-gonic/gin")func main() { r :=gin.Default() r.GET("/weather", func(c *gin.Cont

前言利用模版生成，来对常见的重复的编码，进行一键生成。使用代码生成，解决的是以下问题:大幅度减少开发时间，将常见工作过程流水化。降低新人使用门槛。减少后台和前端的对接时间。减少重复劳动里容易出错的概率。代码风格统一。代码生成最常见的业务场景:CRUD业务缓存xml转gojson转goprotobuf转goproto-rpc转go1. 业务流程1.1 生成业务模型与缓存支持import mc "github.com/fwhezfwhez/model_convert"

前言服务间调用，作为客户端的一方，必须防止服务不可用，而造成客户端服务崩溃，引发雪崩。调用方必须对每一个不可靠的服务调用，做到【熔断】机制。【熔断】: 当某一个请求单位时间内，失败次数达到阈值时，该类请求进入熔断状态。熔断状态下，后续请求将直接返回错误，而不会真的去请求等待超时。熔断状态存在持续时间。【熔断的作用对象】: grpc服务调用的客户端角色, http服务调用的客户端角色, tcp服务调用的客户端角色。分析可以基于redis实现分布式熔断器。可以基于单点实现熔断器。熔断操作必须

前言goroutine是golang的重点特色。由上层语言自实现的协程概念，在使用者层面，他的作用等价于线程，但是使用者不需要关注线程资源，线程调度，线程模型等底层原理。使用一个go协程也非常简单go func(){ fmt.Println(111)}()尽管他的设计和实现都非常轻量，但是在实际团队项目里，因为错误的协程使用，仍然会给团队带来不少隐患，相信大家都遇见过以下问题:发现了内存泄漏问题，继而定位到了数量爆炸的goroutine数量。因为想要在业务里，增加一段其他业务的异步

前言api服务里，幂等场景在【写入】场景非常重要。它包括了:修改任务进度领取奖品充值……幂等的作用，是防止某一次操作，在并发调用时，意外地执行了不止一次。(理论上，不论执行多少次，执行结果，都应该和一次相同)幂等的实现往往围绕某一个key, key具备一定的业务含义:基于路由规则/x/xx/x/ 和接口限频有关基于用户id 和用户请求限频有关基于订单id 和充值相关幂等是如何保障【写入】场景的安全的以基于订单id的幂等为例。用户凭借订单id来获取道具，同一个时间

背景为了应对更多的流量冲击，决定将业务的redis迁移到集群里。后端应用是golang开发的。源: 单机redis目标: 腾讯云redis集群3主0从条件: 集群redis内已有数据，非空迁移经过1. DTS先采用腾讯云官方的DTS切换方案，失败。失败原因: DTS只支持节点数据迁移到空集群。2. 决定重构redis组件，按照下述流程完成迁移第一步，所有应用双向写入源和目标redis，读写返回值取源返回值。第二步，保持15天+。确保未同步的缓存正常失效，新缓存全量同步。第三步，所