- 博客(28)
- 收藏
- 关注
RSS订阅
原创 linux系统ubuntu18搭建C、C++开发环境
最近想学习在linux下的C、C++开发，以便能具备跨平台能力，网上查看了些前辈高人的各种搭配经过甄选后，决定自己的搭配如下：ubuntu18的linux系统、编译器自是gcc、g++的不二选择、编辑器利用vim-plus一键安装版（Vim加上各种以搭配好的适用插件）。系统选择：ubuntu是近年慢慢流行起来的一个linux分支系统，既然是较为流行那么出问题资料就比较好找，所以选择该系统，并未用20最新版，选择用18个人觉得稳定性会稍好些。从阿里的镜像下载安装包，地址为：http://mirrors.a
2020-09-14 20:43:18
741
原创 通用服务平台---总结
从事服务端开发多年，由开始的一无所知，到渐渐有点经验，到近年一直在想是不是可以搭建相对较为通用的服务平台，让业务方无需关注诸如通信，日志，系统数据等等细节，仅需专注自身业务即可，且该平台能被多个不同业务所共用，以便减少开发，提高构件复用性。以自己积累的经验来考虑通用平台需要提供那些基础功能、怎样将这些基础功能抽象出来作为通用构件复用、通用平台实现存在什么样的难点、通过怎样设计能提高系统扩展性和稳定性。经过近段时间的考虑沉淀，目前也有相对清闲时间，于是就有了通用服务平台设计系列博客。本篇是通用服务平台总结，概
2020-06-09 16:53:36
558
原创 日志Log类设计
日志功能是一个不可或缺的应用基础功能，客户端、服务端都会日常使用，其中服务端的日志功能相对更加需要，在日常维护工作中，当服务端出现问题时，很多时候需要日志功能来配合寻找出现问题的原因。日志功能虽然非常基础、非常常见几乎各公司都会提供基础类来支持该功能实现，本人也看过一些日志基础类，作为基础构件，我觉得还是有必要说说我自己对日志基础类的一些设计关键点，一来可以为初入门的开发者提供参考思路，二来也可以为需要进行日志类优化的同行们，提供参考。一、日志类功能1. 输出日志，作为日志类的核心基本功能当然是不可
2020-11-26 19:14:06
1104
原创 通信服务性能信息收集及处理
衡量后端通信服务器的好坏优劣，有各种参数，如服务器响应速度、吐吞量、抗压能力、等等这些参数大多是从不同角度出发，侧重服务器不同的性能点，用来辅助判断服务器的好坏，是否达到预定目标。我个人认为，后端服务在保证逻辑正确性的前提下，首要是稳定性。稳定性压到其他各参数，一个服务性能再好，得要活着才能提供服务。其次才是性能，在稳定性有保障的前提下，自然是性能越优异越好。各个性能参数之间，其实关联性很强，很多时候解决了其中一个问题，各个性能指标都会有提升，那么这些性能参数中那些是最重要的，这些参数在调优之后，对于整体服
2020-11-18 20:16:38
219
2
原创 浅谈通信服务基类设计
互联网时代，通信服务非常常见，看过一些开源工程、工作过公司的工程，对于应用层基础类的设计相对于通信库而言，欠缺很多，导致应用层代码相对逻辑不够不清晰，也给以后的维护带来一定的难度。本篇就是讲述通信服务在上层应用基类设计的一些个人观点和看法，仅起到抛砖引玉，给出一个不同的设计，各位读者如有不同的设计思路，可以留言讨论。一、基类设计范畴。基类设计范畴较广，所以在本篇开启前，需要确定设计范畴，以免丢失主要目标。一般通信服务工作处理流程都是从底层通信库接收业务数据包开始，经由底层回调应用层进行逻辑处理，最后
2020-11-17 20:35:10
267
原创 STL+Template打造“万能”数据模板
在使用C++进行日常开发过程中，基本都会使用STL或者是类似的基础库，以便提高开发效率。STL库提供的那些数据结构实在是很好用，如map、list、vector这些能轻松方便的在工程中直接使用，如果是不含指针的常用类型基本STL就已经实现了“万能”的数据模板，除了线程安全之外。本篇就是讲述利用STL库中那些现有的诸如map、list、vector数据结构，并且模仿他们的实现方式，来打造一个线程安全的“万能”数据模板。一、为什么要打造“万能”的数据模板。为什么已经有了STL，还需要再打造一个呢？...
2020-11-17 00:29:17
174
原创 windows下利用完成端口（IOCP）搭建客户端网络库
本篇是网络库系列之客户端网络库，基于IOCP搭建，由于是windows系统特有，所以只能在windows系统上运行。惯例，本篇将从应用场景、技术要点、网络库主要设计及关键细节，这几个方面介绍，希望能给大家一点启示，能从中获益。由于在本篇之前，已经有了一篇介绍使用IOCP搭建服务端网络库的博文，所以本篇会将与之重复部分简略介绍，如果大家在阅读本篇时，感觉不明白或者有疑虑，请参照windows下利用完成端口（IOCP）搭建服务端网络库，或者在博文之后留言讨论。1. 应用场景windows下网络IO模型.
2020-10-12 20:47:29
557
原创 gdb代码调试流程及常用调试命令简介
linux环境下进行C、C++开发系列，前面已经发了三篇博客，分别是系统选择和环境搭建、编译工具cmake简介、以及vim-plus开发日常使用指令简介。本篇将向读者讲述如何在linux下进行使用gdb工具进行代码调试。代码调试我认为是每个程序员必备的技能，在某种程度上甚至超越编码本身，毕竟没有程序员在代码生涯中不会产生bug，调试就是找到bug产生原因，并解决bug的最佳手段。本篇将向读者讲述gdb的使用，和常用的gdb调试指令。1. 生成debug版可执行文件在编码过程中时常需要检查我们编写的代
2020-09-17 20:03:26
468
原创 vim-plus编辑及常用插件快捷键简介
前两篇为大家介绍了在linux系统下，如何搭建一个C、C++的开发环境，介绍linux系统选择，编译器的选择，和编辑器的选择，以及为了摆脱编写底层makefile痛苦及考虑跨平台功能，而选择cmake来进行辅助编译。至此准备工作已经基本完成，可以着手写上一段代码，本篇就是为大家介绍vim-plus一键安装版编辑器在日常开发过程中的使用，本篇假设各位读者已经在ubuntu系统上成功安装vim-plus，如未能安装的，请移步查看我相关开发环境搭建的博客。编辑器，一般需要满足日常文本的编辑功能，这部分功能设计
2020-09-16 21:57:59
622
原创 跨平台编译利器cmake、摆脱makefile苦海利器cmake
上篇给大家介绍了如何在linux下的ubuntu系统搭建C、C++的开发环境，现在已经有了操作系统，有了GCC、G++的编译器，有了vim-plus的编辑器，那么是不是就可以直接编码了呢？理论上是已经具备了编码的环境和条件了，事实上当然仅仅写代码也是没有任何问题的，但是如果需要在写完代码之后，继续进行代码的编译，那么我们还缺少一个环节，那就是本篇将要介绍的一个相对编码而言前置的编译问题。我们在编写完代码之后，需要借助G++来对我们编写的C++代码进行编译，将高级语言编译成机器可识别、执行的机器语言，G++是
2020-09-15 20:53:07
317
原创 windows下利用完成端口（IOCP）搭建服务端网络库
服务端网络库是后端服务体系基石，网络库性能高低决定服务性能起点。本篇简介在windows下利用完成端口来搭建服务端网络库。1. 技术选型windows下网络IO模型大致有：select模型、WSAAsyncSelect模型、WSAEventSelect模型、重叠I/O模型、完成端口模型，共五类模型。（一）select模型贴近底层使用socket基础函数，封装简单易开发，但性能不太高，适用小量连接。（二）WSAAsyncSelect模型基于windows消息系统模型，和界面窗口易于配合便于开发
2020-06-15 21:32:06
618
原创 通用服务平台之应急仲裁处理
应急仲裁处理是通用平台一个较为独特的构件，其他系统较为少见，本人维护过的各系统都未见过踪影，引入该构件相当于为通用平台引入一个为系统保驾护航的安全机构，这个安全机构实时监测系统运行状态，在系统可能出现问题之前，就能敏锐捕捉到先兆然后根据预定义处理方案，进行一系列的容灾措施，将系统从危险状态慢慢牵引回正轨，保障系统一直处于良好运行状态。...
2020-06-08 20:41:15
134
原创 运维子系统之运维节点
运维子系统是通用平台重要的基础构件，运维节点则是运维子系统最重要，最基础的构成部分。运维节点被部署在每台服务器上，维护该台服务器上所有的运维任务。运维节点功能上篇已经描述，本篇简介运维节点实现上相关要点。1. 守护功能守护功能作为一个7x24小时运行系统而言是必不可少的，再稳定服务也有发生异常的时候，在服务异常退出运行后，就需要有一个守护来启动服务再次投入运行状态，通用平台设计运维子系统来承担该任务，具体由运维节点来进行服务守护工作。每台服务器上都被部署了运维节点，每个运维节点负责本机上所有服务的守
2020-06-07 15:27:23
652
原创 通用服务平台之日志子系统
日志系统在服务体系中较为常见，其基本功能就是及时抓取服务最新的运行日志然后进行上报或持久化。通用平台日志子系统功能也是如此的，因为功能较为基础普遍，先给出结构示意图，然后再简介子系统。日志子系统架构示意图1. 日志子系统构成日志子系统构成较为简单，由数据发布服务、捕捉节点、数据写入三部分组成。（一）数据发布服务。负责将日志系统配置DB中的初始数据和后续的变化数据发布至数据子系统，该部分较为简单不做赘述。（二）捕捉节点。捕捉节点负责整个服务器上N个运行服务日志的捕捉工作，根据子系统.
2020-06-05 20:49:01
536
原创 通用服务平台之通信子系统
通信子系统是通用平台重要模块构件之一，负责整个平台内部通信功能。本篇将简介通信子系统设计相关细节。1. 通信子系统意义服务间直连大多数系统服务间基本都采用直接连接方式进行通信，该方式优缺点分析如下。优点：1. 通信节点少，延迟低。2. 便于逻辑处理，有些业务处理很可能附加在链路状态上，所以该类方案有天然逻辑处理优势。缺点：1. 各服务都需要维护大量系统数据，且需要进行数据同步。2. 如果后向服务规模较大，需要维护多根通信链路，对服务处理性能不利。3. 服务间通信是多对多的连线，不便于维护
2020-06-04 20:28:57
982
原创 数据子系统之数据代理
数据子系统中的数据代理是为了屏蔽数据子系统中的复杂性，为使用者提供一个统一入口和友好界面。本篇简介数据代理的相关设计。1. 数据代理功能（一）接受数据使用者数据请求。这是数据代理最为常用的功能，也是对外提供最为基础功能。数据代理根据请求数据包中给出的数据Key检索本机房数据与数据节点映射数据，找到所承载的数据节点，将请求数据包转发至数据节点。如果映射中没有该数据信息，则向中控发起资源申请，在本机房建立该数据存储。（二）接受数据发布者数据发布请求。代理在接收到数据发布注册请求后，遍历本机房该数据是
2020-06-03 22:24:28
304
原创 数据子系统之数据节点
数据节点是数据子系统真正执行数据存储访问的服务集群，是数据子系统中主体，其稳定性和服务性能直接决定数据子系统可用性和响应速度，该部分相对较为复杂，面对诸多不稳定因素，需要在设计阶段就开始考虑各种异常情况和极端情况，以便规避由设计带来的系统天生缺陷和短板，制约数据子系统健壮性进而制约整个通用平台健壮性。本人水平有限，尽力把个人对于该部分的设想描述清楚，让各位读者能通过该篇博客了解作者设想的数据节点是如何工作。并希望对于各位读者能有所启发，如果有感兴趣的同行，或是该方面经验更为丰富的大佬指出错误发起讨论指点一二
2020-06-03 00:36:22
4789
原创 数据子系统之中控
本篇介绍数据子系统中的中枢--数据中控服务。数据中控在数据子系统中相当于人体中的大脑，虽然不进行实际数据的存储，但是该服务负责整个数据子系统中新数据注册、过期数据销毁、数据节点负载调度、数据源信息维护，等等重要功能，是数据子系统中枢核心。本篇将简介该服务相关关键点。1. 数据中控功能点（一）数据注册。数据注册是数据子系统中基础功能，既所有需要在数据子系统存储数据都需要先进行数据注册，告知子系统即将有新的数据注入子系统，同时数据发布服务在数据注册返回数据包中获取数据Key值和存储节点信息，以便将数据发
2020-05-31 22:38:57
1050
原创 通用服务平台之数据子系统--概述
本篇介绍通用平台相对较为重要构件之一数据子系统的总体概要，给出数据子系统全局架构，和基本组成部分。介绍数据子系统功能设计、应用场景、和设计相关重要关键点，以便衡量该子系统在通用平台中存在必要性和该子系统需要完善到何种地步。让我们先从该子系统功能和应用场景开始，之后再给出架构图和讨论设计关键点。1. 数据子系统功能设计数据在现在的各个业务产品中变得越来越重要，各个业务操作或多或少最后都会归结于数据，业务的展开，后端服务的配合几乎都围绕这数据这个核心信息。常见业务系统关于数据基本都是各自为政，某类业务数
2020-05-30 23:12:30
1382
原创 通用服务平台之消息处理子系统
消息处理子系统是通用平台为各业务系统提供的两类消息处理功能，一类是针对单个客户端的消息推送功能，另一类是针对一个群发组的消息群发功能。这两类消息处理大同小异，只是处理系统的获取的映射数据不同，单个客户端消息处理需要获取客户端路由映射数据，群发消息处理需要获取是群发ID和代理服务的映射数据。除映射数据不同外，转发处理机制一致。消息处理子系统与平台其他构件配合运行示意图如下： ...
2020-05-29 17:21:48
747
原创 通用服务平台之系统数据发布
系统数据发布构件在通用平台中功能较为单一，却较为重要，因为系统数据发布构件是整个通用平台系统数据源，承担着系统数据发布重任，包括全量初始化数据和后续的变化数据同步工作都将交由该构件完成。同时设计提供一定量的系统数据修改接口，以便其他服务能有机会更改系统数据，起到隔离系统DB的作用。该构件与平台中其他构件运行状态如下图： 系统数据发布构件与系统其它构件配合示意图如上图所示，系统数据发布构件直连系统DB，从D...
2020-05-28 19:31:37
513
原创 通用服务平台之地址分发
地址分发其实先于代理服务被客户端所链接，这是由地址分发功能所决定。地址分发是整个通用平台唯一对客户端发布服务数据的服务，其功用也是为客户端提供所需的服务数据。客户端、地址分发、代理或其他业务服务关系示意图如下： 地址分发示意图如上图可知客户端在无任何服务端数据时，首先从地址分发获取服务数据，之后才能根据获取的服务数据向服务发起连接进行业务交互。那么这里面就...
2020-05-27 22:55:25
350
原创 通用服务平台之总体架构设计（二）
本篇是通用服务平台总体架构设计第二篇，继续上篇尚未完成的模块构件功能应用简介。6. 数据子系统提到后端服务，就绕不开一个核心关键词--数据。不管什么样的业务系统，大规模、小型、简单业务、复杂业务基本最后都是围绕数据部分而展开，所有业务逻辑操作都将体现在数据变更上，在数据这个关键敏感部分收尾。后端服务设计时常需要考虑的问题是从哪里拿到业务数据？修改后的数据如何存储？如何通知业务服务修改后的数据？等等诸如此类和数据相关的问题。同样通用平台虽然被设计为与具体业务无关，但依然有维持平台自身正常运转的必要数据
2020-05-27 00:40:49
1071
原创 通用服务平台之总体架构设计（一）
一晃从事软件行业已经有多个年头，而从事服务器相关后端开发，也有了不少的年头，维护过中小型系统，也曾亲身设计过小型系统，但是一直都感觉不太顺意，不是自己想要的那种服务体系，很多时候都是在重复造轮子，于是一直在想是不是有可能存在一套通用的服务平台，提供与业务无关的后端服务通用功能，将这些功能糅合成一个通用服务平台，使得各产品线共享该平台提供的相关功能，各使用者仅需专注自身业务逻辑，减少重复造轮子机会，既加快了开发进度，压缩了开发成本，同时也能利用平台提升系统健壮性、可扩展性和维护便捷性。近一年来终于有了相对较为
2020-05-26 15:00:22
3528
原创 通用服务平台之通用代理服务（二）通用代理服务关键细节设计
本篇为通用服务平台系列第二篇，是关于通用代理服务关键细节设计的相关描述。让我们一起来看看通用代理服务如何兼容各个不同产品线，如何设计才能具有一定的自适应性，已达到通用特性，及降低代理服务升级部署代价。1. 统一协议必要性因为是通用代理需要兼容各个不同的产品线，各自协议可能都不同，那么这种情况就需要统一协议来将各系统协议差异进行屏蔽才有可能通用化，这是基础前提条件。不管是已有产品线接入，还是新加入产品线，都可以通过发布客户端通信库，将统一协议实现封装在内来解决。客户端无需了解统一协议细节，现有协议也无
2020-05-24 23:56:17
452
原创 通用服务平台之通用代理服务（一）通用代理服务功用和主要职责
本篇为通用服务平台系列第一篇，是关于通用代理服务功用和主要职责的相关描述。关于通用代理服务后续还有关键细节设计的一些个见和常用解决方案，写该系列文章用意是抛砖引玉，让广大服务器开发同好们加以讨论，以期向各大佬们学习！1.常用代理服务功用一般各服务器体系中通常都存在代理服务，在本人多年从事服务器开发历程中，接触的每个服务体系都存在有代理服务，非常常见也非常实用，那么常用的代理服务它的功用是什么呢？我试着总结一下，大致有如下几点：（1）起隔离作用。一般代理服务居于客户端和目标服务之间，这么设计之后，
2020-05-20 23:03:02
842
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人