模仿微信App 主要功能： 1. 登录页面：注册与登录功能 2. 聊天列表：点击进入群聊，单聊，公众号。右上角加号能进行拉人创建群聊的功能。 单聊：能进行正常信息的发送（语音功能以及播放功能写了，但是有点bug，页面出不来没找到原因） 群聊：能进行正常信息的发送，模拟了接收信息的功能 公众号：点击底部导航进行相应功能，模拟了消息接收功能 3. 联系人列表：常用联系人+页面导航（群聊列表+公众号列表）点击均可进入相关页面，并且在聊天列表显示。 4. 发现页面：能进行不同的喜好页面的切换。点赞以及收藏按钮的简单使用 5. 我的设置页面：退出功能、点击头像进入设置自我信息页面 6. 个人设置页面： 点击-- 头像：拍照换头像和从系统相册选取头像（这里还是会有点问题，不知道是不是虚拟机的问题） 名字：设置并且能在聊天页面 性别：选择性别并显示 微信号：更改与多个活动显示 二维码：时间定时切换或者点击切换，用户昵称、性别的显示

+ springBoot + springCloud + 日志组件logback-spring + 多配置 + 多数据源 + swagger2 + 异步线程池配置 + mybatis-plus + 令牌token + 全局异常管理 + 统一返回数据拦截 + 自定义异常 + 处理ajax跨域请求 + Feign + 熔断机制 + eureka + 单元测试(controller、service、mapper层) + redis集群集成练习 + redis操作练习 + fastDFS集成练习 + 全局拦截器 + 定时器配置 + 定时器任务设计[线程池+分布式锁] +关闭挂钩 + 单例应用 + 自定义配置集成 + AOP注解两种模式切面练习 + 项目启动预处理 + 自定义编辑事务架构 + 上传下载 + 传参注解式校验 + session练习 + 公用日志设计封装 + db乐观锁设计 + 优雅启停 + 配置文件信息加密 + AES加解密 + spring 事件监听设计

考研资料

“孪生”的概念起源于美国国家航空航天局的“阿波罗计划”，即搭建两个相同的航天飞行器，其中一个发射到太空执行任务，另一个留在地球上用作反映太空中航天器在任务期内的运行状态，进而辅助工程师深入分析处理太空中发生的突发事件。当然了，这里的两个航天器全部都是真实存在的物理实体。

最新一键部署H5即时通讯/带群聊/可封装APP/可任意二开 好友分享的一键端，这次真的是不傻都能部署起来了，传上去，访问自己的域名，就可以直接安装了。几分钟就装完，萌新都可以瞬间拥有自己的即时通讯平台了。可以单独封装APP出来，这个东西主要的用途是带单，以及嵌入一些推广用的东西。。。至于这个东西到底怎么玩更合适，我估计不用说了，可任意二开。算是很不错的东西了，最近都没找到什么很合适分享的东西，这个我就觉得很不错，直接分享给大家

在开始今天的话题之前，简单的来看有关Python的体系结构。为了方便起见我做一张导图，让大家有个宏观的认识。今天本来准备全面的聊聊有关高性能并发这个话题来着，但是周末马上要来了啊。所以我就取了其中的一点来介绍，关于其他的方面，有兴趣的小伙伴可以和我交流。谈高效并发，往往脱离不了以下三种方案：1.进程：每个逻辑控制流都是一个进程,由内核来调度和维护。因为进程有独立的虚拟地址空间，想要和其他控制流通信必须依靠显示的进程间通信，即我们所说的IPC机制2.线程：线程应该是我们最为熟知的。它本质是运行在一个单一进程上下文中的逻辑流，由内核进行调度。3.I/O多路复用：应用程序在一个进程的上下文中显式地调

基于微服务或者SOA的自动化测试系统每个公司都有自己的特有的，我今天就主要介绍一下，我们研发的一套mock测试系统。我公司目前用的是基于Dubbo的微服务改造，服务之间的调用链路冗长，每个服务又是单独的团队在维护，每个团队又在不断的演进和维护各个服务，那么对测试人员将是非常大的挑战。测试人员每次进行功能测试的时候，测试用例每次都需要重新写一遍，无法将测试用例的数据沉淀，尤其是做自动化测试的时候，测试人员准备测试数据就需要很长时间，效率非常低。目前接口自动化测试框架也多种多样，testng，junit，Fitnesse等，但都需要测试人员具备测试代码编写能力，如果要做好和手工接口测试一样效果的自

经历过需求的采集、分析和筛选，我们对产品的定位和用户的需求有了越来越深刻的认识，对整个产品方向的把控和版本迭代节奏也会更有感觉。这种感觉你也可以称之为“产品感”，虽然讲得有点悬乎，可又的确存在。以我个人的经验来看，不断地了解用户需求和场景，也是积累产品感的一种良好的方式。有了不错的产品感，我们要继续往前走，才能将产品推向一个更高的高度。产品经理之前已经将产品第一个版本的功能需求都整理好了，也输出了一份详细的功能需求列表，这个时候要做的工作就是为产品搭建一个好的架构，也就是产品设计的第三个环节——搭框架了。任何一款互联网产品都应该有一个产品架构，有了这个强大而坚实的架构作为产品的基础，我们才能将

本文来自于cnblogs，文章详细介绍了两个分布式系统的理论:CAP和BASE理论以及分布式事务解决方案：CAP等。最近很久没有写博客了，一方面是因为公司事情最近比较忙，另外一方面是因为在进行CAP的下一阶段的开发工作，不过目前已经告一段落了。接下来还是开始我们今天的话题，说说分布式事务，或者说是我眼中的分布式事务，因为每个人可能对其的理解都不一样。分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免，本文就分布式事务来简单聊一下。在说分布式事务之前，我们先从数据库事务说起。数据库事务可能大家都很熟悉，在开发过程中也会