第一次准备搞微服务架构的时候还是在 2021-03-14 16:13:56 ，当时，我准备系统的让自己深入到微服务架构里，彻底的了解这一切。
之前只是了解或者知道这个概念，虽然，公司也会有此类的架构，但是，当时的认知对它了解还是太少，就像ABP这样的成熟的框架一样，看着文章，或者公司有架构师之类的职务的人封装好了，来用吧，小伙子。
然后，吭哧吭哧的敲业务代码，遇到了问题，让你去解决的几率也很低，解决成功的几率也很低。
这个时候，深入了解它是由什么组成的，如何组成的，就显得很重要，当然，对我自己来讲是这样的。
虽然，大佬可以直接看源码，解决问题，但是，我又不是啥大佬，所以，从基础中来，到基础中去。
至今，我已经对微服务整体有一个简单且相对深入的了解了。并对其中的多个组件有了清晰的认识。
我想把这些过程分享出来，第一是让自己更深入的了解，第二呢，也想在这个过程中交到更多的好朋友，这样才能走的更远，第三呢，想找到一些正反馈的信息，让我知道自己做的这个事情有啥好和不好。
总之一句话，你了解的代码，才是可控的，你不了解，它就是一个坑，还会陷害你。
我们不能了解更细，那么，只有尽量了解了
微服务的发展（自述）
单体在早期能解决我们的业务问题，但是随着用户量，设备量的增长，并发量的上升，已经不足以支撑整个业务系统。
这个时候，就得采用硬件+软件的方式来解决这样的问题。
如果公司有钱，可以直接通过提升硬件（服务器硬件配置+带宽）来解决问题。
但是，大部分公司还是要节省这部分的开销的（阿里云等云平台收费还真是不便宜），所以，要从多个角度来解决这个问题，那就是性价比。
像HBase这样的列式数据库也是利用大量闲置的硬盘资源来做大数据量的存储的应用，我们就可以用技术和性价比比较好的资源去做事情。
分布式，是解决这个问题的，当你的业务一个支撑不了，我们就给你上两个，一个人解决不了，两个人应该就够了吧。
但是，解决的人多了。就需要一个管理层来管理谁来处理啥，就像有人请假了。你得让另外一个人替补，要不然，就没办法继续流程下去，所以，这个管理层是必须存在的。
这里说一下我对分布式和集群的理解。
分布式，就是把业务拆分为一个又一个的步骤，比如做饭，选菜，掌勺，上菜，支付。
分开每个部分做自己的那个部分业务。集群：就像搬砖的，一个人不够，我就多分配给你几个人，你们都是干的一样的事情。
从广义理解，它其实也是分布式。
微服务
分布式总得来说，偏向一个大的概念，而微服务，把重心放在了服务的拆分与服务的管理上，偏具体一点。
但是，从概念上，微服务还是基于分布式概念来拓展的。这样就容易理解整个体系了。
微服务的技术栈
- 服务注册与发现
- 网关
- 进程通讯框架
- 分布式追踪
- 日志收集和分析
- 配置中心
- 鉴权中心
- 分布式事务
- 负载均衡反向代理
- 任务调度
- 分布式系统监视
- 可视化数据管理及分析
- 容器化
- CICD
也可以参考下图
我都搞过哪些
- 服务注册与发现
- 进程通讯框架
- 配置中心
- 负载均衡反向代理
- 任务调度
- 容器化
当然，有些技术栈包含内容多一些，有些也不容易搞环境。
总的来说，一半一半吧。
可见，深入了解每个细节，也挺不容易的。
分布式理论
这个理论知识，可以每天一点一点的了解，吸收，缺少不了的。
我顶多写一些实战，但是，理论基本都是从论文来的，我可写不了论文。
总结
接下来，我会慢慢的把每个技术栈，能实现的细节给一一展现，一起进步。
注
总的核心是，如果单体能解决问题，就没必要分布式，能不分布式，就不要分布式。
分布式之后，大大的增加了系统的复杂性。
排查问题就增加了几个数量级，遇到问题风险可能就会上升。
