分布式架构设计
一、前言
随着微服务的流行，“分布式架构”作为高频词时常出现在开发者面前，我们是否理解分布式架构？它和微服务有什么区别呢？这一小节我们将讲解微服务和分布式架构那些事。
二、概念
1、分布式：
将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互。区别分布式的方式是根据不同机器不同业务。
上面：service A、B、C、D 分别是业务组件，通过API Geteway进行业务访问。(注：分布式需要做好事务管理)
2.分布式是否属于微服务？
答案是肯定的。微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。
3.微服务架构
微服务的设计是为了不因为某个模块的升级和BUG影响现有的系统业务。微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。
4.分布式服务架构与微服务架构概念的区别与联系是怎样的
分布式：分散压力，不同模块部署在不同服务器上，分布式解决网站高并发带来问题，通过负载均衡设备共同对外提供服务,业务系统分解为多个组件，让每个组件都独立提供离散，自治，可复用的服务能力;通过服务的组合和编排来实现上层的业务流程;
微服务：分散能力，架构设计概念，各服务间隔离（分布式也是隔离），自治（分布式依赖整体组合）其它特性
（单一职责，边界，异步通信，独立部署）是分布式概念的跟严格执行;
5.传统架构
传统项目的架构： 特点：1.all in one(所有模块在一起，技术也不分层)，2.servlet(jsp).... 缺点：1.并发量差2.容错性差(不具有高可用性)
注：不具有高可用性的意思是，比如当用户访问时，服务器后台因为一些原因导致服务器崩溃，用户就能直接看到错误页面，服务器也因为错误从而停止运行(宕机)，这就叫做不具有高可用性。
传统架构不在过多介绍，在某个业务场景下，该架构需要演进，这就今天我们说的分布式架构
一般的it公司，基本都是采用集群架构，因为这种架构方式已经基本能满足需求了，但是一些大型项目，这种方式就显然是力不从心了，只能采用分布式的架构方式
6.分布式框架的优点：
-
大幅提高并发访问量(10000+)
-
可以节省成本(因为这种优化仅是从架构方面进行优化，而不需要去配置大量的服务器)
-
实现了服务层与表现层的解耦合
注：
-
其实还有一种方式，即是提升带宽，把带宽搞多一点，但前提是服务器能承受这么大的量。
-
集群也不是越多越好的，越多的话就会发现，其实并发的提升是有限的。
三、微服务架构SpringCloud
springcloud是微服务架构的集大成者，将一系列优秀的组件进行了整合。基于springboot构建，对我们熟悉spring的程序员来说，上手比较容易
开发者常用的5大组件以及其他组件（如下图所示）：
服务发现——Netflix Eureka
客服端负载均衡——Netflix Ribbon
断路器——Netflix Hystrix
服务网关——Netflix Zuul
分布式配置——Spring Cloud Config
但是由于种种原因，目前springcloud gateway和nacos在网关和注册中心、配置中心作为开发者常用方案。
在微服务常用组件选型上，可以多了解下各组件的优势，然后选择适合我们团队的技术栈。
常用架构：
随着业务在不断发展，技术架构也需要不断的调整来应对需求的变化。
如下是某网站的演化最终架构图，我们分析下
上图一个比较完整的现代微服务架构，从外到内依次分为：端用户体验层->网关层->BFF层->微服务层。整个架构层次清晰，职责分明，是一种灵活的能够支持业务不断创新的演化式架构。
用户接口的请求首先经过网关层（如springcloud gateway），在网关层可以实现功能
路由，将来自无线设备的请求路由到后端的某个微服务BFF集群
认证，对涉及敏感数据的API访问进行集中认证鉴权。
监控，对API调用进行性能监控。
限流熔断，当出现流量洪峰，或者后端BFF/微服务出现延迟或故障，网关能够主动进行限流熔断，保护后端服务，并保持前端用户体验可以接受。
安全防爬，收集访问日志，通过后台分析出恶意行为，并阻断恶意请求。
...
BFF层：所谓BFF其实是Backend for Frontend的简称，中文翻译是为前端而开发的后端，它主要由前端团队开发（后端微服务一般由后端团队开发）。BFF可以认为是一种适配服务，将后端的微服务进行适配（主要包括聚合裁剪和格式适配等逻辑），向无线端设备暴露友好和统一的API，方便无线设备接入访问后端服务。
网关在无线设备和BFF之间又引入了一层间接，让两边可以独立变化，特别是当后台BFF在升级或迁移时，可以做到用户端应用不受影响。
网关承担了重要的角色，它是解耦拆分和后续升级迁移的利器。在网关的配合下，单块BFF实现了解耦拆分，各业务线团队可以独立开发和交付各自的微服务，研发效率大大提升。另外，把跨横切面逻辑从BFF剥离到网关上去以后，BFF的开发人员可以更加专注业务逻辑交付，实现了架构上的关注分离(Separation of Concerns)。
之后的微服务层我们就比较熟悉了，注册中心、生产者、远程调用等
建议架构：
总体来说上图架构在一些大型互联网采用还是比较多的，但是要根据我们的项目规模以及日后发展趋势选择是否需要BFF层，也就是说在某种情况上图中架构某一层是可以适当调整的。
三、小结
微服务和分布式架构在企业中应用广泛，但是同样也会带来一些问题，如运维成本、敏捷开发、开发人员学习成本高等，所以要根据团队人员综合技术水平选择适合团队的架构开发项目。
转载：https://blog.csdn.net/zzhuan_1/article/details/108422145