微服务架构需要考虑的问题
首先搞清楚，集群是个物理形态，分布式是个工作方式，
分布式是指将不同的业务分布在不同的地方。分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成
当然分布式肯定属于微服务。
微服务的设计是为了不因为某个模块的升级和BUG影响现有的系统业务。微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。
分布式和微服的架构很相似，只是部署的方式不一样而已。
首先微服务，或者说分布式要遵循CAP
一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）
1、服务间的调用
2、服务的注册发现
3、服务的容错（高可用）
4、数据调用及传输
5、API Gateway
6、服务的部署
定义
架构为了解耦，实际开发的方式采用分布式系统开发，围绕业务领域，业务领域定义了边界，DDD领域驱动设计，来创建组件应用，这些应用可以进行独立的开发，管理和迭代。在分散的组件当中使用云架构和平台式部署，管理和服务功能，使产品交付的更快
本质
用一些功能比较明确，业务比较精炼的服务去解决更大、更实际的问题。
微服务这个概念在2012年提出来的
与传统架构的区别
系统架构遵循三个标准
1、提高敏捷性：及时响应业务需求，促进迭代
2、提升用户的体验：减少用户流失
3、降低成本：降低增加产品、客户或者业务方案的成本
传统开发模式
和微服务相比，这种模式称为单体开发
所有的功能打包在一个WAR包里，基本没有外部依赖（除了容器），部署在一个JavaEE容器（Tomcat，JBoss，WebLogic）里，包含DO/DAO，Service，UI等所有的逻辑
优点：
1、开发简单，集中式管理
2、基本不会重复开发
3、功能都在本地，没有分布式调用的消耗（网络请求，rpc框架）
缺点：
1、效率低：开发都在一个服务当中，冲突问题难以解决
2、维护难：代码耦合度高
3、不灵活：构建时间长，小的修改影响整个服务
4、稳定性差，高可用差：一个问题导致整个大的服务不可用
5、扩展性弱：无法满足高并发下的需求
微服务架构
目的是为了解决敏捷开发和快速迭代的过程
服务之间还有相互调用和同步事务
微服务特征
1、一系列的独立服务共同组成系统
2、单独部署，跑在自己的进程中
3、每个服务单独开发
4、分布式管理
5、强隔离性
标准
1、分布式服务组成的系统
2、按照业务，进行划分，而不是技术划分（领域驱动设计DDD）
3、自动化运维（DevOps）
4、高度容错性
5、快速迭代
微服务要解决的问题
1、这么多服务，客户端如何访问？
2、服务与服务之间如何通信？
3、服务如何治理？
4、服务挂了怎么办？
解决
1、当客户端多ip问题，或者移动端（APP），那么APP更新，只有20%的人更新，剩下80%不更新，那就出现访问问题，这时候需要API Gateway管理，API的域名可以保持不变。
首先几个概念
Route（路由）：这是网关的基本构建块。它由一个ID，一个目标URI，一级断言和一组过滤器定义。如果断言为真，则路由匹配。
Predicate（断言）：输入类型是一个ServerWebExchange。我们可以使用它来匹配来自HTTP请求的任何内容，例如headers或参数
Filter（过滤器）：Gateway中的Filter分为两种类型，分别是Gateway Filter和Global Filter。过滤器会对请求和响应进行修改和处理。
网关的功能
1、请求接入：作为所有的API接口服务请求的接入点
2、业务聚合：作为所有后端业务服务的聚合点
3、中介策略：实现安全、验证、路由、过滤、流控等策略、
4、统一管理：对所有API服务和策略进行统一管理
2、对于内部通信，RPC通信，最大的好处就是传输效率高，可以进行压缩（序列化），那么就有解压（反序列化）
对外就是REST（也需要序列化和反序列化），这里需要两次序列化和两次反序列化，多一次将对象序列化转Json，再序列化Json，而且对象还大
对于微服务当中最主要的问题，各个服务之间的通信是最重要的，那么要解决的就是服务之间数据传输的过程，一是数据传输的速率，二是数据传输的安全性，对于内部服务通信，也就是内网通信，保证长连接以及传输的数据包比较小，不建议大对象数据的传输通过rpc进行，对外使用http，也就是在不同的局域网，那么这种防火墙也只有字符串才能进行无状态传输，而rpc是二进制数据，就不能进行跨局域网传输
对于各个服务是独立部署在机器上，那么出现的问题就是要服务注册与发现，要保证各个服务的ip注册和后期调用对应服务的发现
这里可以根据实际业务场景去选用合适的服务注册发现的技术选型，因为对于微服务要保证的就是高可用，从始至终都要保证网络抖动和丢包的可能性，那么就要保证所有通信都要有自己重试机制，也就是消费端一定都要做幂等的措施
3、那么服务注册与发现，这里一定有所有服务的注册IP列表
聚合器微服务设计模式
最简单的设计模式
聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的web页面，将检索到数据进行处理展示。它可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。
代理微服务设计模式
聚合模式的一个变种。
在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理仅仅委派请求，也可以进行数据转换
代理不同与聚合的点是可以转发到对应的服务
链式微服务设计模式
这种模式在接受到请求后会产生一个经过合并的响应
在该情况下，service A接收到请求后会与service B进行通信，同样 B C也会相互通信，所有服务都使用同步消息传递。在整个链式调用完成之前，客户端一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。
分支微服务设计模式
基于聚合器模式扩展，可以同时调用两个服务
数据共享设计模式
这时候可能C、D服务共用分支模式，可能将优惠券和优惠券详情两个服务
异步消息传递设计模式
使用MQ实现各个服务之间的调用