标签：图片 业务逻辑 请求 页面 客户 相同 变化 gate 需求
1.微服务原理图
图片来自于网络，如有侵权，请联系博主，立即删除
图片从右向左来看：
（1）为服务最主要的目的就是实现，如果说软件a使用了购物车程序作为后台，同时软件b也使用了购物车作为后台，那么如果软件a和b都是同一家公司开发的，那么他们就不需要写相同的代码，为软件a和b同时都写一个后台，它可以将后台的服务拆分，分别为了很多，如：认证，购物车，用户，商品，支付等等，需要什么功能就直接去取相关的实现程序调用即可。
（2）BFF此时，每次访问该页面都需要发送 3 个请求。同时为了保障app，第三方和Web 端的不同需求，需要为不同的平台写不同的 API 接口，而每当值发生一些变化时，需要 Android，iOS，Web 做出修改。与此同时，当我们需要对一个字符串进行处理，如限定 140 个字符的时候，我们需要在每一个客户端（Android，iOS，Web）分别实现一遍，这样的代价显然相当大。
于是，我们就需要 BFF 作为中间件。在这个中间件上我们将做一些业务逻辑处理
而当我们有了 BFF 这一层时，我们就不需要考虑系统后端的迁移。后端发生的变化都可以在 BFF 层做一些响应的修改即可，无需修改app，同时也修改web端。
（3）网关：对于一些跨横切面的关注点（cross cutting concerns），例如路由，安全认证，日志监控分析，限流等等，通常可由独立的网关（Gateway）层负责，下面是用一个网关将所有的切面关注点全部处理的例子。值得注意的是，单节点的 API网关为每个客户端提供不同的API，而不是提供一种万能风格的API。(就如同最上面的图示一样)
也可以是多个网官API，有的网关API处理安全，限流等等，其他网关API处理超时，缓存等等。
2.微服务与SOA
3.微服务与分布式
一个是分散压力，一个是分散能力。
标签：图片 业务逻辑 请求 页面 客户 相同 变化 gate 需求
原文地址：https://www.cnblogs.com/Gbeniot/p/10394025.html
