简单聊聊架构的演变：项目从单机到集群再到微服务架构
单机
项目早期 单机运行 开发中涉及到一些状态都是本地内存存储 例如ConcurrentHashMap存储在线用户信息.
集群
后期业务增长单机慢慢不足以支持，这时候考虑到要弄集群了。
实时在线用户信息，之前是存在本地内存ConcurrentHashMap ，一旦部署了多台机器运行之前的单机应用 会出现集群间同步问题。
要考虑 集群节点的动态增删， 某节点突然挂掉 等,会不会对现有服务造成什么不好的影响，能不能接受，不能就考虑解决
分布式锁
单机多线程 数据同步可以用jdk提供的 synchronized 方法或代码块
但是集群多进程间 jdk提供的线程同步方法synchronized … 方法就无能为力了，这时引入 分布式锁，常用redis实现分布式锁
分步式锁 实现，怎么实现， 要考虑各种极端问题， 要多思考
https://blog.csdn.net/a704397849/article/details/97805420
数据库mysql
一个系统的瓶颈大都是在数据库上，那么急需缓解数据库压力，常用的（出去数据库优化：缓存、语句优化，索引、引擎等）减少数据库访问的方法 缓存(redis 或 memcache等) 、消息队列异步对数据库写，主从复制+读写分离，一些记录日志信息改存非关系型数据库如mongodb 等等。
缓存
设置缓存过期一样导致同时到期
击穿（如某个不常用接口访问的数据没做缓存） 黑客利用
缓存集群，节点崩溃 或 增减集群节点 会怎样
缓存集群的算法 一致性哈希， 为什么选择这个，这个算法有什么优缺点，如何实现
redis 缓存 单线程为什么性能高，引入nio, 那nio是什么 如何实现高性能 …
用 redis 分布式锁实现 …
消息队列
https://blog.csdn.net/a704397849/article/details/98598927
为什么要用消息队列，优缺点是什么
优点:解耦，异步 提高响应速度，削峰 给服务器降压
缺点：实现麻烦了一点,可用性降低
消息队列集群 要考虑的问题，消息队列存放的数据 如何保证数据库的安全 可靠？ 集群某个节点死了，增加节点 会怎么样,存储在消息队列的数据会丢失吗，如果保证 如何保证的，保证数据不丢失 会不会存在重发，存在重发 那我如何在应用中解决重发问题 等等。 不管什么集群 都考虑各种极端情况，前面 项目单机到集群 也提到了一些极端问题。
消息队列有很多，常见 activemq rabbitmq , rocketmq ,kafka
影响框架性能的因素有很多，实现语言、架构、算法等
这里只想提一下 架构
activemq rabbitmq 集群采用 主从架构， rocketmq ,kafka 集群采用分布式架构
提到主从架构 又想到 mysql 集群常用 也是主从架构， 那主从架构是什么样的架构 有什么优缺点
向主节点写入，然后慢慢同步拷贝到从节点 ，读操作访问从节点(当然也可以访问主节点)
又引入了 数据一致性问题: 强一致性 和 弱一致性
主从架构： 数据是弱一致性，缺点 不保证集群数据同步一致，但保证数据最终一致，这个过程需要一定同步拷贝时间，优点性能比强一致性高
选择 强弱一致性 要看项目需求，大部分情况 弱一致性 比较好，当然对数据 同步有需求 可以选择强一致性架构
又引入 CAP原则
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
…
提到数据一致性 又联想到 一致性hash 算法，有什么 联系 ？
一致性哈希 对比 普通哈希 nginx 哈希策略 , 一般缓存选择一致性hash原因：主从分布式保证一致性的缺点，一致性hash的缺点： 但是可以接受
微服务
单机项目 顺利改造成了 集群后，还不够所有的功能全部柔和在一个项目中，经常会出现因为一个小的功能模块修改而重启整个服务。
这样不好，引入了微服务架构,微服务架构将项目分细，每个小模块是一个微服务，微服务模块项目部署多个就是该微服务项目的集群，要能集群部署就的考虑前面提到的多机同步问题，如果存在集群间共享的数据要考虑如何处理，选择缓存还是消息队列还是其他的方法等等。
微服务架构
主流 dubbo 和 springcloud
…
单点登录
微服务 功能细分了 可能有多个功能模块都需要登录，如果每个模块都实现一个自己的登录 耗时费力不说，而且不好维护管理。引入 单点登录概念，单点登录实现 用token 比较好实现
JWT token
java 提供了一套标准的token 实现协议 JWT
https://blog.csdn.net/a704397849/article/details/98692032
…
容器
随着用户增长，服务器数量不断扩张 部署的应用增长，上线越来越麻烦部署 ，容器docker 可以解决这个问题
最后
上面只是很随意的简单介绍,临时想写点架构的东西，还有很多点并没有提到，后面会花时间详细整理一份比较完整的介绍。上面一些知识点我只是提了一下，在我之前的博文里面或多或少都有一些相关文章，有兴趣的可以看看，如果写的不好，可以提出来，我会花时间改善。