一、走向单体地狱
1.怎么如何走向单体地狱
我们通常一个项目的几个模块，最终打包成一个war包就叫做单体应用，随着业务程序的不断扩展，已经发展成为一个只有少数来发人员能够理解的巨大单体，它使用了过时、非生产性技术编写，这使得招聘雨哦修开发人员变得非常困难。应用程序变得难以扩展，不可靠。因此敏捷开发和应用的交付是不可能的。
2.微服务-解决复杂问题
- 他的思路是将应用程序分解成一套较小的互联服务。一个服务通常实现了一组不同的特性或功能，例如订单管理，客户管理等。每一个微服务都是一个迷你应用，它自己的六边形架构包括了业务逻辑以及多个适配器。
- 一些微服务会暴露一个供其他微服务或应用客户端消费的API。其他微服务可能实现了一个web UI。在运行时，每个实例通常是一个云虚拟机或者是一个Docker容器
- 在运行时，TripManagement服务由多个服务实例组成，每个服务实例是一个Docker容器，为了实现高可用，容器时在多个允许你及上运行的。服务实例的之前时一个类似于NGINX的负载均衡器，用于跨实例分发请求。负载均衡器也可以处理其他问题，如缓存，访问控制，API度量和监控。
- 微服务架构模式明显影响了应用程序与数据库之间的关系，其每一个服务都有自己的数据库模式。一方面，这种做法与企业级数据库模型的想法相悖，此外，它经常出现数据冗余。然而，如果想要从微服务中收益，每一个服务都应该有自己的数据库模式。他能实现松耦合。
- 高可用：一直可以用，不会宕机
- 根据不同的应用，采用不同的数据库技术，有的适合mysql 有的适合 redies
- SOA:面向服务架构 ，类似于微服务
- 从表面上看，微服务架构类似于SOA.微服务是由一组服务组成，换另一种方式去思考微服务架构模式，她是没有商业化的SOA，没有集成web服务规范（WS-)和企业服务总线。基于微服务的应用支持更简单，轻量级的协议，例如，REST，而不是WS-.我们也尽量避免使用ESB，而是实现微服务本身具有类似ESB功能。微服务构架也拒绝了SOA其他部分，例如，数据访问规范模式概念。
微服务架构模式有许多非常好的地方
二、注册中心Eureka,Zookeeper,Consul的异同点
| 组件名 | 语言 | CAP | 服务监控检查 | 语对外暴露接口 | Springcloud集成 |
|---|---|---|---|---|---|
| Eureka | Java | AP | 可配支持 | HTTP | 已集成 |
| Consul | Go | AP | 支持 | HTTP/DNS | 已集成 |
| Zookeeper | Java | AP | 支持 | 客户端 | 已集成 |
三、CAP
1.CAP定理：
一个分布式系统最多只能同时满足一致性、可用性、和分区容错性这三项中的两项
- 一致性（Consistency）：即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致
- 可用性(Availability)：即服务器一直可用，而且是正常的相应时间
- 分区容错性(Partition tolerance)：即分布式系统在遇到某节点或网路分区故障的时候，仍然能够对外提供一致性和可用性服务。
2.CAP权衡
- 对于多是大型互联网应用场景，主机众多，部署分散，而且现在的集群规模越来越大，所以节点故障，网络故障是常态，而且要保证服务的可用性达到N个9，即保证P和A,舍弃C.虽然某些地方会影响到客户体验，但是没有达到用户流程的严重程度（比如顾客下单，网络崩了，数据库没有收到订单信息这就是流程故障）
- 对于钱财这样不能由一丝让步的场景，C必须保证。网络发生故障宁可停止服务，也要保证CA。
