1.集群和分布式
1.1 集群是个物理形态，分布式是个工作方式
- 分布式：一个业务分拆多个子业务（节点），部署在不同的服务器上
- 集群：同一个业务，部署在多个服务器上
1）分布式是指将不同的业务分布在不同的地方。而集群指的是将几台服务器集中在一起，实现同一业务。分布式中的每一个节点，都可以做集群。而集群并不一定就是分布式的。
2）简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
3）微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
1.2 演进路径
单体架构->分布式结构(缓存性能瓶颈)->微服务架构(实现业务敏捷性)
2.分布式和微服务
1).服务拆分粒度
分布式架构:
按功能模块拆分（如用户模块、订单模块），粒度较大且模块间存在一定耦合。例如传统金融系统将核心交易模块独立为Dubbo服务，其他模块仍保持单体结构共享数据库。
微服务架构:
按业务能力细粒度拆分（如支付服务拆分为支付路由、风控服务），每个服务实现单一职责。例如Netflix将系统拆分为1000+微服务，每个服务独立开发部署。
2).通信方式与技术约束
分布式架构
依赖RPC（如Dubbo）或消息队列（如Kafka），通信协议较重（如SOAP）。技术栈统一（如全Java体系），便于维护。
微服务架构
使用轻量级协议（REST/gRPC），避免中心化ESB。支持多语言开发（如Go、Java、Python混合），例如Uber使用gRPC实现全球订单调度。
3). 数据管理
分布式架构:
允许共享数据库（如MySQL分库分表），依赖分布式事务（如Seata）解决数据一致性，但对跨库JOIN容忍度较高。
微服务架构:
强制"Database per Service"原则，每个服务独立数据库（如MongoDB、Cassandra），通过事件驱动（如Kafka事务消息）实现最终一致性。
4). 部署与扩展
分布式架构
模块级部署，扩展需整体调整（如新增订单服务需同步扩容负载均衡器），成本较高。
微服务架构
容器化（Docker）+编排（Kubernetes）实现秒级扩缩容。例如电商大促时，推荐服务可单独横向扩展。
4).未来趋势
-
混合架构：分布式与微服务融合，例如核心交易模块使用分布式架构保证强一致性，边缘服务采用微服务实现快速迭代。
-
服务网格：将通信治理下沉至基础设施层（如Istio），降低业务代码侵入性。
-
无服务器架构：结合Serverless（如AWS Lambda）进一步提升资源利用率。
5).总结
选择分布式架构：适合技术栈统一、运维能力有限的团队，应对中等复杂度业务。
选择微服务架构：适合追求极致弹性、技术自由度高且具备成熟DevOps能力的团队。
核心差异：微服务是分布式架构的特例，但更强调自治性、细粒度拆分和云原生适配。