SpringCloud微服务 分布式架构设计

前言

微服务架构 = 80% 的 SOA 服务架构思想 + 100% 的组件化架构思想 + 80% 的领域建模思想

最新项目比较忙，没有时间给自己充电，刚好在项目中有做过一些分布式架构设计也提供了具体的解决方案，现在整理一下，对我对分布式架构设计/应用/演变的理解。先看一张图：

上图是我自己整理的一个微服务架构解决方案脑图，仅用于阐述我自己对微服务模式构建的分布式架构的理解与实际的应用场景说明。这个脑图我将持续维护并持续更新，不喜勿喷。有兴趣的可以互相学习或者来过过招。。。

最近因项目紧张，没有时间写自己的博客，于我而言这确实是一种损失。个人的成长离不开团队氛围的熏陶，更离不开个人的勤奋好学与实践。这一两周连续面了很多人，总的来说感觉每个人多多少少离我的期望值有些偏差，即便如如此这些偏差我仍能接受并且坚信通过团队的协作与共同成长可以消除我的偏差认知，彼此之间会更加了解，合作也会更加顺利和愉悦的。

我仍记得一个使我影响非常深刻的场景，面试时一个和我差不多大的小伙子在面试后问了我两个问题：

• 为什么你想要了解的问题浅尝辄止，感觉没有深入地做沟通和交流？

  当我被这样询问时，第一直觉是可能我在与他沟通的过程中表现出来的专业能力使他觉得我不够强，或者我没有足够的技能储备来维持与他的交流。实际上是我在很积极地去引导他去他熟悉了解的领域去发挥(他在他的简历上有着重说明对分布式系统有深刻地理解并熟练掌握一些常用的分布式解决方案)，结果他的回答都很表面，而且对于一些分布式解决方案并没有实际的场景应用经验。于是我很委婉地告知他说，我和他的沟通秉着真诚了解和互相尊重的原则，我会主动地去引导你往你所擅长的领域去深入了解，如果你给不了我任何惊喜，那么也没必要继续深入了，那样会觉得我是个不懂得尊重人的人。
  所以在面试的过程中，如果你对自己擅长的领域表现的不够优秀或者不自信的话，面试官很有可能降低Ta对你的期望值，同时你也会失去更多表现自己的机会。

• 你面试时，对技术这个块你最看重什么？

  在我面试了这么多的人中只有这么一个面试者询问了我这么样的一个问题。这倒不是说我是什么什么样子的人，而是在这样面试经历中我发现一个很有趣的现象就是：很多面试者对自己的了解和定位不够清晰也不够坚定，而一些面试官也无法准确地说明他到底需要什么样子人时，沟通的效果和效率明显不好。所以在面试的场景中，面试者要明确地知道：我是一个什么样子的，我能胜任什么样子的工作，可以适当地标榜自己，但切记不要过头，除了你的专业技能之外，你的谈吐/思维/自信心/自我掌控能力/表达能力等等都很重要。面试官也要明确地知道：我想要一个什么样子的人，我希望Ta能具备什么样子的能力以便以后更好地开展工作和合作。
  当我被这样子询问时我思考了近5秒钟，然后很正式地告诉他：我需要一个具备理解分布式架构思想并能够任性延申的人。
  在我看来任何技术解决方案都是一种用来解决问题的工具，而分析问题和制定解决方案的这个过程的思维历程非常重要，这也能充分体现一个人的逻辑体系是否成熟，解决问题的能力是否强大。所以在面试时我一般都会要求面试者向我阐述一个比较完整的解决问题的过程。比如如果面试者说他使用Redis做过分布式缓存，那么我就会问：请你简单地描述一下你是怎样使用Redis来实现分布式缓存机制来支撑你的业务场景的？别小看这个一个问题，里面包含了非常非常多的细节与要点，比如说分布式缓存是否有用专门的服务来实现，在集成Redis时我们需要特别注意什么(对象存贮序列化问题)，如何制定Redis数据持久化机制(AOF/RDB问题)，Redis分布式缓存集群的主从机制怎么实现的，是否有用到分布式锁等等。。。。

使用这个多废话只为为阐述我的一个观点做铺垫：任何开发工作，思维逻辑和设计实现的过程尤为重要。做分布式架构必须要有足够的敏感度感知到未来架构演变的方向并且能够做好规避潜在危险的应变能力，比如说早期架构设计地不够简洁，扩展性和稳定性不好等等，同时也要有做分布式架构的思想和各种解决方案或预备方案，通常而言我们做一个分布式架构都会具备以下模块或者功能：

• 服务注册与发现
• 服务与服务通信高可用
• 统一服务网关
• 统一API管理
• 统一APM管理
• 服务性能监控
• 统一日志管理
• 分布式
• 统一认证授权中心
• 分布式缓存
• 分布式事务
• 分布式消息队列
• 版本控制与灰度发布
• Docker化与CI/CD(快速部署与发布-K8S-Paas)
• 子服务或者业务的边界的如何确定(DDD指导思想与方法论)
• 常用的公共工具
  • 统一任务调度
  • 文件服务器
  • 敏捷开发代码生成器
  • Mybatis Plus
  • …
• …

在一开始设计一个分布式架构时架构的基础服务一般不会如上的所有功能，而且也非常不建议这样做，架构是会演变的，我们不必要求架构一开始就具备完备的功能，但我们必须清楚地在知道架构的演变方向并能轻易地掌控演变方向，这样才能在构建分布式架构的整个架构生命周期中得心应手。