悟世之路

2024-06-04 架构-不同层次的抽象的处理-分析.

最近在抽出时间做一个数据库的driver, 其中有些问题驱动的软件代码的思考，是很值得回味的。做的系统，所思考的问题，所设计的解决方案，其实都是可以看作是对解决问题方式。而不仅仅是某个类库的API的使用，某个算法的实现复杂度，某个固定的设计模式，或者设计规约。

2024-05-24 思考-关于软件架构设计。

虽然很难估算出这究竟能挽救多少项目，但是在我十多年职业生涯中，经历的和近距离观察的几十个项目，确实看到了大量的项目正是由于代码质量不佳导致的失败和遗憾，同时我也发现其实失败项目的很多问题、症结也确确实实都可以归因到项目代码的混乱和质量低下，比如一个常见的项目腐烂恶性循环：代码乱》bug 多》排查问题耗时》复用度低》加班 996》士气低落……国内基本上是这样，国外情况我了解不多，不过从英文社区和技术媒体上老外同行的抱怨程度看，应该是差不多的，虽然整体素质可能更高，但是也因更久的信息化而积累了更多问题。

软件系统有不同的抽象层次，可以在不同的细粒度上分析评估。一个充满了复杂业务的系统，一般是通过拆分成不同的小的系统部分，类似分治算法的策略，进行开发。对于其中涉及的因素，进行分析和评估。

创业失败的直接因素便是资金链断裂无法支撑, 但是这个只是最终的结果，而导致资金链断裂导致无法进行下去, 这个过程中的诸多因素就需要慎重的分析, 就像有句谚语说的，成非成于成之日，败非败于败之时.由于涉及的因素有多重侧面, 所以分多个文章逐个分析, 本文探讨技术层面.

目录摘要:要点:理论层:实现层:摘要:从使用角度,总结最近使用raft的记录要点:理论层:raft与paxos的区别 对问题的简化 增加对要解决的问题的限制 raft分为哪几个子问题 leader选举 日志复制 数据安全 raft对每个不同的子问题如何解决 有哪些数据不一致的场景 failover时如何保证数据一致性实现层:划分成多少个不同性质的服务 } 服务间交互接口如何设计 每个服务可划分成哪些组件...

目录摘要:raft业务代码:main.go:application.go:启动raft集群:启动raft节点:组件raft三节点的集群:查看集群信息:查看主从切换过程:nodeB日志:nodeC日志:重启nodeA, 查看nodeA日志主从切换结论:摘要:组建三节点的raft集群, 及研究主从切换的过程raft业务代码:main.go: package mainimport ( "context..

目录摘要:raft测试代码:raft-grpc-example:raftadmin:快速组建raft集群:一. 生成需要的文件目录二. 分别启动一个bootstrap节点和两个常规节点三. 给bootstrap节点增加follow节点摘要:简单测试raft, 给出快速测试例子的方式raft测试代码:raft-grpc-example:https://github.com/Jille/raft-grpc-exampleraftad

摘要:说明zkfc的思想, 评估其设计的优劣zkfc说明:https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.htmlThe ZKFailoverController (ZKFC) is a new component which is a ZooKeeper client which also monitors and manages the

摘要:记录redis-cluster集群, 单点故障的检测情况时序图:

[在此处输入文章标题]摘要:网络传输中的字节流,分析进一步优化的空间问题发现:在对现有网络数据抓包分析过程中, 发现存在”00\ 00\ 00”空字节的重复序列, 抓包数据如下:统计数据如下:”00\ 00\ 00”对于信息编码而言,未表示有价值的数据. 但是否能剔除这种冗余的连续空字节, 需要通过分析序列化协议,研究出现的原因, 从而针对性的解决冗余的连续空字节.序列化过程, 用数学模型表示...

开发了很多年，做了很多系统，非常感谢那些给我机会公司，也非常感谢给我指导的人。但是成长的路，最重要的是需要自己的思考，更需要从实际经验中反思。本篇文章的目的，在于为了后续职业的长久的生命力，切入更为深入的赛道。有以下问题需要深入反思:redis 单个节点的redis，一条更新语句执行流程是什么 redis的不同数据结构, 内部是如何实现的, 为什么要用这样的方式实现? 分布式的redis，cluster集群的数据是如何分布的 redis的主从，在整个集群中，是怎么切换的 .

测试架构层的理解:对现有架构组织的理解 炫舞手游组中玩家数据查询相关 服务交互规则 Zone服与Lobby服交互规则 Zone服广播的注册和通知机制 中心服广播式的大区玩家数据同步, 能支撑的PCU是多少 玩家数据拆分成的不同子集的属性区别 玩家simple数据的获取方式 玩家summary数据的获取方式 玩家LRU缓存的管理 缓存过期的控制机制是什么 缓存容量限制的控制是什么 向缓存添加数据的时机是什么

简略:以更为合理的方式对third服task进行调整.模块拆解:协程调度 third服线程间的工作模型 third服任务的生命周期与处理后数据 third服任务的执行结果与调度结果协程调度:说明:协程的概念可以理解为用户态线程, 直白说就是用户态中, 保存当前执行上下文 用户态调度, 即恢复保存的上下文, 切换不同的上下文linux内核中一个最小的调度单位为task, 进程和线程对内核来说都是task, 区别只是在创建新的task时候调用clone时指定...

简略服务器组中, 目前的third服,集合了所有的对第三方访问的业务. 但是不同业务的权重不同,对cpu和io, 以及安全性, 有不同的需求. 对该服做横向拆分,以分割不同的业务.

此文存在的原因是前事不忘后事之师.记录这次任务中经验.对于一个任务最开始的分析,以确定问题的边界,具体的理解便是,和哪些模块交互,依赖模块所提供的接口是什么,对其他模块的影响是什么,本模块提供的对外的接口是什么,从而锁定该问题,表现出来,便是,与sdk方通信,涉及网络交互目前使用的是应用层协议http/https,该协议的使用工具是libcurl库,https依赖于openssl,与平台方...

作为一个开发者, 能力在哪些地方? 其次, 能力是如何锤炼出来的? 这些是每天都要反思的事情.而这个问题必须自己不用力去思索并去笃行自己的思考.这个问题有很多不同的视角, 对公司而言, 能力取决于解决的问题. 但对于个人来说,可迁移的能力才是自身持续进步最关键的.可迁移性在技术层面的具体表现,便是对一个新的技术的掌控力和一个以前未解决过的问题ji决力. 也就是说, 对于出现的新的技术, 应...

默认服登录逻辑 CH3DMobileConnectionManagerLogin::login 服务器限制校验， 本服是否在维护状态 客户端限制，现在什么也没做 签名校验 同一个token，不同的玩家 客户端ip白名单 建立会话 通过token会话查询player，已绑定player 登出状态，无效 正在处理状态，无效 客户端发送重连 ...

1．创建型模式创建型模式，就是创建对象的模式，抽象了实例化的过程。它帮助一个系统独立于如何创建、组合和表示它的那些对象。关注的是对象的创建，创建型模式将创建对象的过程进行了抽象，也可以理解为将创建对象的过程进行了封装，作为客户程序仅仅需要去使用对象，而不再关系创建对象过程中的逻辑。社会化的分工越来越细，自然在软件设计方面也是如此，因此对象的创建和对象的使用分开也就成为了必然趋势。因为对象的...

最近一段时间协助处理了一些持续集成相关的业务，算是接着这个机会对整个架构的各个方面都有所了解。持续集成包含服务器和客户端，服务器需要单独说明，这里说明客户端。客户端的持续集成，涵盖了客户端代码的持续提交，自动导出客户端的安装包，自动化的将安装包推荐入商店。有点类似于devops，就是尽可能的自动化。这方面的工具，选取的是jenkins，工作是将一些流程写进jenkins的pipeline中...