什么是微服务：

微服务架构是一种架构模式，它提倡将单一的应用程序划分成一组小的服务，服务之间互相调用，互相配合，每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相协作
微服务的核心是“服务治理”，服务治理的核心是“服务划分”

演化过程：

早期的单体服务：

例如开发一个商城，最多也就分为前后端，后端将用户注册，店铺管理，商品管理，商品展示，订单支付，物流管理，评价系统等模块顺序延伸开发，最终所有模块开发完成的代码合并在一起统一编译部署上线，这样开发人员需要全面理解整个业务，贯穿整个生产流程
单体式应用内部包含了所有需要的服务。而且各个服务功能模块有很强的耦合性，也就是相互依赖彼此，很难拆分和扩容。

集群：

当单体服务一旦出现故障，整个网站就得停止运转，这个时候集群登场，就是把单体程序同时部署到多台服务器，然后再用nginx类似这种工具实现负载均衡

微服务：

随着互联网产业的发展，一些公司的业务已经非常庞大，如果还是单体开发批量部署的模式显然很难进行有效管理。这时就有一些企业从业务层面分割原有系统，比如对电商平台可以把以前完整统一的系统分割为商品展示，用户管理和支付平台三大部分。每个部分单独开发独立部署，他们之间使用轻量的API调用进行数据交互。这样每个部分都可以由不同的团队互不干扰的独立开发，只要彼此遵守事先约定的规则。
单个应用程序被划分成各种小的、互相连接的微服务，一个微服务完成一个比较单一的功能，相互之间保持独立和解耦合，这就是微服务架构

• 微服务的优点：
  • 技术异构性：单个应用程序被划分成各种小的、互相连接的微服务，一个微服务完成一个比较单一的功能，相互之间保持独立和解耦合，这就是微服务架构
  • 隔离性：单个应用程序被划分成各种小的、互相连接的微服务，一个微服务完成一个比较单一的功能，相互之间保持独立和解耦合，这就是微服务架构
  • 可扩展性：单个应用程序被划分成各种小的、互相连接的微服务，一个微服务完成一个比较单一的功能，相互之间保持独立和解耦合，这就是微服务架构
  • 简化部署：单个应用程序被划分成各种小的、互相连接的微服务，一个微服务完成一个比较单一的功能，相互之间保持独立和解耦合，这就是微服务架构
  • 易优化
• 关于微服务的一些概念：

服务注册与发现：

服务监控：
以往单体应用，排查问题通常是看一下日志，研究错误信息和调用堆栈。而微服务架构整个应用分散成多个服务，定位故障点非常困难。
这个时候我们提供监控

定位错误- 链路跟踪：
在微服务架构下，一个用户的请求往往涉及多个内部服务调用。为了方便定位问题，需要能够记录每个用户请求时，微服务内部产生了多少服务调用，及其调用关系。这个叫做链路跟踪。
链路跟踪只能定位到哪个服务出现问题，不能提供具体的错误信息。查找具体的错误信息的能力则需要由日志分析组件来提供。

分析问题-日志分析
日志分析组件应该在微服务兴起之前就被广泛使用了。即使单体应用架构，当访问数变大、或服务器规模增多时，日志文件的大小会膨胀到难以用文本编辑器进行访问，更糟的是它们分散在多台服务器上面。排查一个问题，需要登录到各台服务器去获取日志文件，一个一个地查找（而且打开、查找都很慢）想要的日志信息。
因此，在应用规模变大时，我们需要一个日志的“搜索引擎”。以便于能准确的找到想要的日志。另外，数据源一侧还需要收集日志的组件和展示结果的UI组件：


小明调查了一下，使用了大名鼎鼎地ELK日志分析组件。ELK是Elasticsearch、Logstash和Kibana三个组件的缩写。

• Elasticsearch：搜索引擎，同时也是日志的存储。
• Logstash：日志采集器，它接收日志输入，对日志进行一些预处理，然后输出到Elasticsearch。
• Kibana：UI组件，通过Elasticsearch的API查找数据并展示给用户。

网关 - 权限控制，服务治理
拆分成微服务后，出现大量的服务，大量的接口，使得整个调用关系乱糟糟的。经常在开发过程中，写着写着，忽然想不起某个数据应该调用哪个服务。或者写歪了，调用了不该调用的服务，本来一个只读的功能结果修改了数据……
为了应对这些情况，微服务的调用需要一个把关的东西，也就是网关。在调用者和被调用者中间加一层网关，每次调用时进行权限校验。另外，网关也可以作为一个提供服务接口文档的平台。

服务注册与发现 - 动态扩容

熔断：
当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时或者收到错误返回。如果调用链路比较长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应。所以当多次访问一个服务失败时，应熔断，标记该服务已停止工作，直接返回错误。直至该服务恢复正常后再重新建立连接。

服务降级：
当下游服务停止工作后，如果该服务并非核心业务，则上游服务应该降级，以保证核心业务不中断。比如网上超市下单界面有一个推荐商品凑单的功能，当推荐模块挂了后，下单功能不能一起挂掉，只需要暂时关闭推荐功能即可。

限流：
一个服务挂掉后，上游服务或者用户一般会习惯性地重试访问。这导致一旦服务恢复正常，很可能因为瞬间网络流量过大又立刻挂掉，在棺材里重复着仰卧起坐。因此服务需要能够自我保护——限流。限流策略有很多，最简单的比如当单位时间内请求数过多时，丢弃多余的请求。