近期笔者因为工作原因,开始启动team内部部分技术项目的重构。在事情启动的过程中,内部对于这件事情的定性和投入有一些争论,但最终还是敲定了下来。其中部分争论点主要在于产品形态,因为事情涉及到跨部门合作,所以产品形态怎么符合双方的利益是比较重要的。在这个前提下,然后才是技术设计上面,怎么能够迎合长久合作的需要。
因此,今天笔者就简单聊一下,怎么去做到让技术架构设计和预期产品形态能够做到有效平衡。
近期笔者因为工作原因,开始启动team内部部分技术项目的重构。在事情启动的过程中,内部对于这件事情的定性和投入有一些争论,但最终还是敲定了下来。其中部分争论点主要在于产品形态,因为事情涉及到跨部门合作,所以产品形态怎么符合双方的利益是比较重要的。在这个前提下,然后才是技术设计上面,怎么能够迎合长久合作的需要。
因此,今天笔者就简单聊一下,怎么去做到让技术架构设计和预期产品形态能够做到有效平衡。
在先前一篇文章中,笔者给大家提到了go语言后端编程可以用wire依赖注入模块去简化单例服务的初始化,同时也可以解决服务单例之间复杂依赖的问题。但实事求是来讲,用wire也是有一些学习成本的,wire在帮助解决复杂依赖的问题同时,也会限定你去用一些特定的编程方式来满足wire的需要,尤其需要你interface给用的更加灵活。
因此今天这篇文章,笔者结合自己的经验,就和大家浅分享下,wire和interface配合的一些经验,让大家以后用wire的时候避免一些坑。
在先前的文章中,笔者分享了go语言monorepo基本的一套代码架构设计。以这个设计为基础,今天这篇文章就聊一下具体里面的代码怎么编写起来比较舒适。
关于每个微服务自己的代码,其实在wire依赖注入这篇文章有提到过一套比较简洁的用法。如果大仓对应的服务集群有很多三方依赖,有很多错综复杂的模块的话,对三方依赖做一层抽象,加上用wire去解决重复依赖问题,是最为舒适的一套解法。当然在这个基础上,其它各模块,尤其是公有模块(lib)需要如何做代码实现,这部分是需要额外推敲的,今天这篇文章就浅聊一下。
最近玩FPS游戏的时候,发现以前一顿操作超频之后的电脑,有一定概率会出问题。具体表现比如一种是,电脑显示器直接黑屏,所有键盘交互没有响应,只能直接重启电脑,还有一种是偶现卡顿,直接死机或者卡出游戏之外。
经过排查和上网查资料发现,可能是由于超频之后,CPU的电压输出不稳定,导致偶现显示器分配到的电压比较少,最终无法正常工作。对于这类情况,笔者分享下自己的一些解决方案:
近期大模型Agent应用开发方面,MCP的概念比较流行,基于MCP的ToolServer能力开发也逐渐成为主流趋势。由于笔者工作原因,主力是Go语言,为了调研大模型应用开发,也接触到了mcp-go这套MCP的SDK实现。
对于企业内部而言,在这个SDK基础上做封装,基本上就能够完善MCP-Server的开发生态。因此今天就简单看一下这个SDK里面,实现了什么东西。
首先是Client连接的实现,这里可以看到每次连接都需要InitializeRequest、InitializeResult以及InitializeNotification这三次握手。从Client角度看逻辑是这样:
最近在AI大模型领域,MCP这个概念非常火,大大小小的公众号都开始对外炒作这个概念,宣教一种新的大模型Agent开发生态。因为工作原因,近期笔者也对MCP和LLM-Agent开发做了一些接触。因此今天这篇文章就浅聊下笔者对基于MCP的LLM-Agent开发方面,自己粗浅的一些理解。
首先还是聊一下什么是MCP,以及MCP在LLM-Agent开发方面,解决了什么问题。
在先前的文章当中,笔者分享了一套简洁的go微服务monorepo代码架构的实现,主要解决中小团队协同开发微服务集群的代码架构组织问题。但是在实际代码开发过程中,怎么组织不同的业务服务service实例,就成了比较棘手的问题。
为什么会出现这样的场景?首先,不同的业务服务可能会用到相同的底层服务,比如DB、缓存、MQ以及三方Client等等。其次,一个底层服务实例可能会在多个业务服务复用,一个业务服务又可能成为另外一个业务服务的依赖。因此这样下来,不同服务实例之间就存在错综复杂的联系,用代码组织起来就比较困难了。
幸运的是,我们拥有wire工具去做go对象的依赖注入,这样就可以用简单的代码实现解决上述问题。在以前的wire文章当中,也简单提到了wire对于微服务框架的作用,但讲解的不算特别精要。所以今天这篇文章,笔者就分享下在go大仓的场景下,怎么用wire去解决service实例依赖问题的,以及怎样才是更加恰当的打开方式。
首先我们要知道wire工具对外暴露了什么能力,有以下一些:
在研发测试日常工作中,通常会遇到很多琐碎的事情,占用我们工作的时间和精力,从而导致我们不能把大部分的注意力放在主要的工作上面。为了解决这个问题,除了加人之外,我们通常会开发一些日常用的效率工具,比如以pyqt、pyside为主体的桌面应用,一键化我们的日常工作,从而解放我们很多处理琐碎事情的精力,让我们有更多精力打磨主业,创造更好的工作成绩。
因此,本文就分享下笔者在24年下半年调研学习pyside6的一些成果,把自己做的小应用homemade-toolset开源出来,供各位有需要的同学参考学习。
整个项目包含时间转换工具、JSON工具以及类似Postman的Request工具,采用python3.11和pyside6开发,目录结构如下:
在先前的文章中,对于变更风险观测的流程逻辑设计,有浅谈一小部分。但从宏观来讲,一个变更观测平台,需要对大量的观测任务做统一调度,这样才能把整个观测平台给支撑起来。因此,本文就简单分享一下,变更风险观测的任务调度可能怎样设计。
这个问题可以拆分为几个子问题:多任务并发需要如何处理,任务调度的消息协议需要如何设计,以及怎么去保证整个调度系统的稳定性。
近期因为项目架构升级原因,笔者着手调研一些go项目monorepo的代码架构设计,目标是长期把既有微服务项目重要的部分都转移到monorepo上面,让代码更容易维护,协作开发更加方便。虽然经验不多,但既然有了初步的调研,今天就分享一下笔者所面临场景的monorepo设计思路。
从语言特性上讲,Golang是非常适合做monorepo的,但根据不同项目研发需要,monorepo的目录结构可以定制成不同的形式。所以要做monorepo,首先要回答的问题是,做这个事情主要解决什么研发问题,优化了什么东西,否则投入量过多,ROI就会很低。