本篇将主要讲解微服务架构究竟指的是什么，它包括了哪些核心组件，它又能给我们带来哪些帮助。
什么是微服务架构
“微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。 每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。 针对具体的每一个服务，可以根据业务上下文，选择合适的语言、工具对其进行构建" Martin Fowler的博客
微服务架构和单体架构
优点
- 提升开发效率，每个服务足够内聚，足够小，代码容易理解。
- 服务独立测试、部署、升级、发布。
- 按需定制的DFX，资源利用率，每个服务可以各自进行x扩展和z扩展，每个服务可以根据自己的需要部署到合适的硬件服务器上。
- 需要选择HA的模式，选择接受服务的实例个数。
- 容易扩大开发团队，可以针对每个服务（service）组件开发团队。
- 提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪。
- 新技术的应用，系统不会被长期限制在某个技术栈上。
缺点
- 没有银弹，微服务提高了系统的复杂度。
- 开发人员要处理分布式系统的复杂性。
- 服务之间的分布式通信问题。
- 服务的注册与发现问题。
- 服务之间的分布式事务问题。
- 数据隔离再来的报表处理问题。
- 服务之间的分布式一致性问题。
- 服务管理的复杂性，服务的编排。
- 不同服务实例的管理。
监控 - 发现故障的征兆
在高并发分布式的场景下，故障经常是突然间就雪崩式爆发。所以必须建立完善的监控体系，尽可能发现故障的征兆。
微服务架构中组件繁多，各个组件所需要监控的指标不同。
比如Redis缓存一般监控占用内存值、网络流量，数据库监控连接数、磁盘空间，业务服务监控并发数、响应延迟、错误率等。因此如果做一个大而全的监控系统来监控各个组件是不大现实的，而且扩展性会很差。
一般的做法是让各个组件提供报告自己当前状态的接口（metrics接口），这个接口输出的数据格式应该是一致的。
然后部署一个指标采集器组件，定时从这些接口获取并保持组件状态，同时提供查询服务。最后还需要一个UI，从指标采集器查询各项指标，绘制监控界面或者根据阈值发出告警。
定位问题 - 链路跟踪
在微服务架构下，一个用户的请求往往涉及多个内部服务调用。为了方便定位问题，需要能够记录每个用户请求时，微服务内部产生了多少服务调用，及其调用关系。这个叫做链路跟踪。
要实现链路跟踪，每次服务调用会在HTTP的HEADERS中记录至少记录四项数据：
- traceId：traceId标识一个用户请求的调用链路。具有相同traceId的调用属于同一条链路。
- spanId：标识一次服务调用的ID，即链路跟踪的节点ID。
- parentId：父节点的spanId。
- requestTime & responseTime：请求时间和响应时间。
链路跟踪只能定位到哪个服务出现问题，不能提供具体的错误信息。查找具体的错误信息的能力则需要由日志分析组件来提供。
分析问题 - 日志分析
日志分析组件在微服务兴起之前就被广泛使用了。
即使单体应用架构，当访问数变大、或服务器规模增多时，日志文件的大小会膨胀到难以用文本编辑器进行访问，更糟的是它们分散在多台服务器上面。排查一个问题，需要登录到各台服务器去获取日志文件，一个一个地查找（而且打开、查找都很慢）想要的日志信息。
因此，在应用规模变大时，我们需要一个日志的“搜索引擎”。以便于能准确的找到想要的日志。另外，数据源一侧还需要收集日志的组件和展示结果的UI组件：
日志服务可以使用ELK日志分析组件。ELK是Elasticsearch、Logstash和Kibana三个组件的缩写。
- Elasticsearch：搜索引擎，同时也是日志的存储。
- Logstash：日志采集器，它接收日志输入，对日志进行一些预处理，然后输出到Elasticsearch。
- Kibana：UI组件，通过Elasticsearch的API查找数据并展示给用户。
网关 - 权限控制，服务治理
拆分成微服务后，出现大量的服务，大量的接口，使得整个调用关系乱糟糟的。经常在开发过程中，写着写着，忽然想不起某个数据应该调用哪个服务。或者写歪了，调用了不该调用的服务。
为了应对这些情况，微服务的调用需要一个把关的东西，也就是网关。在调用者和被调用者中间加一层网关，每次调用时进行权限校验。另外，网关也可以作为一个提供服务接口文档的平台。
使用网关有一个问题就是要决定在多大粒度上使用：最粗粒度的方案是整个微服务一个网关，微服务外部通过网关访问微服务，微服务内部则直接调用；
最细粒度则是所有调用，不管是微服务内部调用或者来自外部的调用，都必须通过网关。折中的方案是按照业务领域将微服务分成几个区，区内直接调用，区间通过网关调用。
服务注册与发现 - 动态扩容
解决这个问题的方案是服务自动注册与发现。
首先，需要部署一个服务发现服务，它提供所有已注册服务的地址信息的服务。DNS也算是一种服务发现服务。然后各个应用服务在启动时自动将自己注册到服务发现服务上。并且应用服务启动后会实时（定期）从服务发现服务同步各个应用服务的地址列表到本地。
服务发现服务也会定期检查应用服务的健康状态，去掉不健康的实例地址。这样新增实例时只需要部署新实例，实例下线时直接关停服务即可，服务发现会自动检查服务实例的增减。
服务发现还会跟客户端负载均衡配合使用。由于应用服务已经同步服务地址列表在本地了，所以访问微服务时，可以自己决定负载策略。
甚至可以在服务注册时加入一些元数据（服务版本等信息），客户端负载则根据这些元数据进行流量控制，实现A/B测试、蓝绿发布等功能。
服务发现有很多组件可以选择，比如说Zookeeper 、Eureka、Consul、Etcd等，也可以开发者自己通过Redis实现。
熔断、服务降级、限流
服务熔断
当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时或者收到错误返回。如果调用链路比较长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应。
所以当多次访问一个服务失败时，应熔断，标记该服务已停止工作，直接返回错误。直至该服务恢复正常后再重新建立连接。
服务降级
当下游服务停止工作后，如果该服务并非核心业务，则上游服务应该降级，以保证核心业务不中断。比如网上超市下单界面有一个推荐商品凑单的功能，当推荐模块挂了后，下单功能不能一起挂掉，只需要暂时关闭推荐功能即可。
服务限流
一个服务挂掉后，上游服务或者用户一般会习惯性地重试访问。这导致一旦服务恢复正常，很可能因为瞬间网络流量过大又立刻挂掉，在棺材里重复着仰卧起坐。因此服务需要能够自我保护——限流。
限流策略有很多，最简单的比如当单位时间内请求数过多时，丢弃多余的请求。另外，也可以考虑分区限流。仅拒绝来自产生大量请求的服务的请求。
例如商品服务和订单服务都需要访问促销服务，商品服务由于代码问题发起了大量请求，促销服务则只限制来自商品服务的请求，来自订单服务的请求则正常响应。
