一、前言
自从大多数web架构从单体演进到服务拆分，到微服务一统天下的几年来，应该没有web应用不是微服务架构的吧。最开始是阿里的doubble分层架构，到后来的SpringCloud全家桶，还有各个大厂自己定义的一套服务治理框架。微服务无处不在，如果你的系统不是微服务的就会被人耻笑落后和垃圾。情况就是这样。微服务确实给web系统开发和治理带来很多的便利性，特别是随着系统越来越复杂的业务。但是是不是业务越复杂也适合用微服务架构呢。显然不是，如果涉及的微服务上千上万，那就有点适得其反。所以个人认为微服务架构适合大中型web项目架构。特别复杂的还有特殊场景下的项目可能并不是很适合。
二、微服务架构要素
1、 Provider(服务提供者)绑定指定端口并启动服务
2、提供者连接注册中心，并发本机 IP、端口、应用信息和服务信息发送至注册中心存储
3、Consumer(消费者），连接注册中心 ，并发送应用信息、所求服务信息至注册中心
4、注册中心根据消费者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。
5、Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。
6、Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer设计的原因：
Consumer 与 Provider 解偶，双方都可以横向增减节点数。注册中心对本身可做对等集群，可动态增减节点，并且任意一台宕掉后，将自动切换到另一台
7、去中心化，双方不直接依赖注册中心，即使注册中心全部宕机短时间内也不会影响服务的调用（Consumer应用缓存中保留提供者 Provider 列表）
8、服务提供者无状态，任意一台宕掉后，不影响使用
注册中心包含如下功能：注册中心、服务注册和反注册、心跳监测与汇报、服务订阅、服务变更查询、集群部署、服务健康状态检测、服务状态变更通知等
三、微服务架构的利与弊
1、单体架构到微服务的演进
2、微服务的优点：
- 灵活性高：它将应用程序分解为小型服务（松散耦合），使其开发、维护更快，更易于理解，可以提供更高的灵活性；
- 独立扩展：它使每个服务能够独立扩展，将系统中的不同功能模块拆分成多个不同的服务，这些服务进行独立地开发和部署，每个服务都运行在自己的进程内，这样每个服务的更新都不会影响其他服务的运行；
- 支持多种编程语言：微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题；
- 自动部署与持续集成工具集成：它允许以灵活的方式将自动部署与持续集成工具集成，例如Jenkins，Hudson等；
- 通用性：通过服务实现应用的组件化（按功能拆分、可独立部署和维护），围绕业务能力组织服务，根据业务不同的需求进行不同组件的使用，所做产品非项目化，对于平台具有一定的通用性。
3、微服务的缺点：
- 处理故障难度高：微服务架构是一个分布式系统，必须构建一个相互通信机制并处理部分故障；
- 部署工作量大：整体式应用程序可以部署在负载平衡器后面的相同服务器上。但对于微服务，每个服务都有不同的实例，每个实例都需要配置、部署、缩放和监控；
- 测试复杂度高：微服务在一定程度上也会导致系统变得越来越复杂，增加了集成测试的复杂度；
- 运营成本增加：整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程；
- 发布风险高：把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险；
- 分布性系统问题：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。
