微服务与分布式
微服务，顾名思义，就是微小的服务。
微服务是一种架构方案。在按照业务需求，将复杂的业务服务，拆分成单独的一个小服务，独立存在，服务内高聚合，服务之间低耦合，它们通过轻量级的通信协议（如HTTP RESTful API或消息队列）进行互动。各个服务可以分别由不同的团队成员来开发维护，甚至使用不同的技术 。
与微服务常常一起提到的另一个概念，分布式。
同样顾名思义，即分布部署。系统由多个独立的节点组成，可以分别部署在不同的机器或容器中。系统之间，一般也通过网络协议进行通信。
微服务与分布式的区别在于：
微服务是从上层业务出发，考虑的是如何从业务的角度来将服务拆分，实现一种模块化的效果。微服务的目的是分散能力。
而分布式，则更多的从技术方面的角度思考，是一种系统面对巨大流量或巨大计算量时的一种解决方案。分布式的目的是分散压力。
微服务和分布式是两个相辅相成的概念。微服务架构通常采用分布式系统的原则和技术，如通过网络通信、负载均衡和数据一致性等。同时，分布式系统可以采用微服务的设计原则，将复杂的系统拆分成更易于管理和扩展的组件。
微服务优缺点
优点：
- 可扩展性：微服务架构允许对单个服务进行扩展，而不是整个应用程序。这有助于更好地满足不同服务的需求，提高系统的整体性能。
- 独立部署：每个微服务可以独立部署和更新，这意味着开发团队可以更快地迭代和发布新功能，同时降低对其他服务的影响。
- 故障隔离：当一个微服务出现故障时，它不会直接影响到其他微服务。这有助于提高系统的可用性和容错能力。
- 技术栈灵活性：由于每个微服务都是独立的，开发团队可以根据服务的需求选择合适的技术栈，而不受整个应用程序的限制。
- 易于理解和维护：微服务架构将复杂的大型应用程序拆分成多个简单的服务，使得开发和维护工作更加容易。
缺点：
- 分布式系统的复杂性：微服务架构引入了分布式系统的复杂性，如网络延迟、数据一致性和服务间通信等问题。
- 运维成本：由于微服务架构涉及多个独立的服务，运维工作可能变得更加复杂，需要更多的资源和技能来管理和监控这些服务。
- 数据一致性：在微服务架构中，数据可能分布在多个服务中，保持数据一致性可能会变得更加困难。 经典问题：分布式事务。
- 服务间通信：微服务之间需要通过网络进行通信，这可能导致性能瓶颈和安全风险。
- 技术栈多样性：虽然微服务架构允许使用不同的技术栈，但这也可能导致团队成员需要掌握更多的技能和工具，增加了学习成本。
项目是否采用微服务的架构，需要看具体的场景。
如果你的业务足够复杂多样，可以采用微服务的架构，将业务解耦。
如果你的业务很简单，只是访问量很大，那可能只需要采用分布式的部署方式即可分担服务器的压力。
在项目初期，如果你对项目预期不是很清楚，不妨先从单体架构做起，后面再拆分成微服务。
微服务架构的考虑，不应该是对未来的考虑，而是对过去单体式应用出现问题后的一种架构重构。
从以往实施微服务的经验教训中，我总结出来的经验，如果是新项目的架构师，可以先选择单体应用，然后根据业务发展一点点迭代重构到微服务上来，即便过程中微服务的架构不那么纯粹，甚至单体应用和微服务很长一段时间共存，也要慎重从新的项目上直接去设计微服务。因为谁也不是算命先生，能估算到自己业务系统会在哪一天，哪个层面，哪个范围就一定需要微服务化解耦。只有系统运行快到那个阶段了，才能让架构师更容易做到合理的微服务化决策。当然了，也有人会有疑惑，系统设计成单体，谁还有心思继续重构微服务，不如直接做成微服务架构多省事，而我想说的是，若无重构之力行，切勿有微服务之念想。
参考
www.ruanyifeng.com/blog/2022/0…
www.redhat.com/zh/topics/m…
维基百科-微服务
developer.aliyun.com/article/105…
www.51cto.com/article/649…
fastonetech.com/newszblog/p…
