背景在很久以前，网站应用是单体应用的架构，流量小，所有功能、代码都部署在一起，成本低。此时数据库访问框架ORM是关键。后来流量逐渐增大，单体应用被拆分为互不相干的多个应用，这就是垂直架构，此时加速前端页面开发的Web框架MVC是关键。再后来，垂直应用越来越大，应用间的交互不可避免，分布式服务框架RPC变成了关键。dubboRPC，全称RemoteProc

前言最近在做一个很复杂的会员综合线下线上商城大型项目，单模块项目无法满足多人开发和架构，很多模块都是重复的就想到了把模块提出来，做成公共模块，基于maven的多模块项目，也好分工开发，也便于后期微服务重构使用场景我刚开始创建项目的时候是基于单模块，开发的，我先开发的接口api项目结构是这样的core模块是公共模块，mallapi是小程序api，随然单体

作为一个有丰富经验的微服务系统架构师，经常有人问我，“应该选择RabbitMQ还是Kafka？”。基于某些原因，许多开发者会把这两种技术当做等价的来看待。的确，在一些案例场景下选择RabbitMQ还是Kafka没什么差别，但是这两种技术在底层实现方面是有许多差异的。不同的场景需要不同的解决方案，选错一个方案能够严重的影响你对软件的设计，开发和维护的能力

因为项目需要，需要打windows安装包，要求安装界面完全按照需求来。作为没接触过这块儿的服务端宝宝，在此期间踩了很多坑。坑不提也罢，最终结果圆满，记录下与大部分网上PO出来的做法不太一样的小心得，备忘。网上搜到的自定义界面，都用的botva2.dll，我没用。应该说，用过，但遇到了图片变形的问题，短时间内没解决，所以最后全都用的 Inno

NFS（NetworkFileSystem）即网络文件系统，是FreeBSD支持的文件系统中的一种，它允许网络中的计算机之间通过TCP/IP网络共享资源。在NFS的应用中，本地NFS的客户端应用可以透明地读写位于远端NFS服务器上的文件，就像访问本地文件一样。简单的来说：它就是是可以透过网络，让不同的主机、不同的操作系统可以共享存储。NFS在文件传送或信

Docker从1.13版本之后采用时间线的方式作为版本号，分为社区版CE和企业版EE。社区版是免费提供给个人开发者和小型团体使用的，企业版会提供额外的收费服务，比如经过官方测试认证过的基础设施、容器、插件等。社区版按照stable和edge两种方式发布，每个季度更新stable版本，如17.06，17.09；每个月份更新edge版本，如17.09，1

Raft分布式一致性算法原理(选举和同步)一.背景在集群环境下，很容易出现单节点故障的问题，那么我们就需要进行集群部署，但是当集群部署的环境下，我们如何保证工作有序的调度与通信并且保证一致性呢，当客户端发送一连串指令，我们需要在集群环境下，所有服务机器最终要保证一致性，而且在出现一系列异常并且恢复

前言本文总结了一些常见的线上应急现象和对应排查步骤和工具。分享的主要目的是想让对线上问题接触少的同学有个预先认知，免得在遇到实际问题时手忙脚乱。毕竟作者自己也是从手忙脚乱时走过来的。只不过这里先提示一下。在线上应急过程中要记住，只有一个总体目标：尽快恢复服务，消除影响。不管处于应急的哪个阶段，我们首先必须想到的是恢复问题，恢复问题不一

众所周知单个机房在出现不可抗拒的问题（如断电、断网等因素）时，会导致无法正常提供服务，会对业务造成潜在的损失。所以在协同办公领域，一种可以基于同城或异地多活机制的高可用设计，在保障数据一致性的同时，能够最大程度降低由于机房的仅单点可用所导致的潜在高可用问题，最大程度上保障业务的用户体验，降低单点问题对业务造成的潜在损失显得尤为重要。