微服务是一种 service 思维， 每一个service 是独立的, 实现敏捷开发和部署.
微服务架构适合有一定的扩展复杂度.
传统的扩展 （把一个copy成两个, 我们目前就是这种）
问题: (下边只列2个吧)
全面扩展, 把压力不大的服务也扩展了2个.
影响开发效率, 因为是一个大应用. 开发, 调试, 大应用本身都在等待中.
如何解决这个问题
大部分企业通过 SOA (Service-Oriented Architecture) SOA 思路是把应用中相近的功能聚合到一起, 以服务的形式提供出去.
这里的服务中间件有一个名词叫 ESB, Enterprise Service Bus. 企业服务总线.
虽然 SOA 解决了单体架构中的问题，但是多数情况下，SOA 中相互独立的服务仍会部署在同一个运行环境中. 和单体架构类似, 随着业务功能的增多，SOA的服务会变得越来越复杂。
微服务架构概念
将系统业务按功能拆分为更加细粒度的服务，所拆分的每一个服务都是一个独立的应用，这些应用对外提供公共的API, 这就是“微服务”。
而围绕着微服务思想构建的一系列结构（开发，测试，部署等）称为 微服务架构
首先, 从 PC 到微服务中间, 还是要有层的, 这里为了简化没画出来.
REST API: 这里指通过轻量的 HTTP 请求, 从而实现标准的 增删改查功能. 分别对应HTTP协议标准的 post, delete, put, get.
微服务的不足:
开发人员要面对分布式的复杂度:
微服务架构组件
服务注册中心: 注册服务的地方
服务注册: 服务提供方将自己调用地址注册到服务注册中心
服务发现：从服务中心找到自己想要的服务地址
负载均衡：服务提供方一般多实例的形式提供服务，使用负载均衡能够让调用发连到合适的服务节点。
服务容错：通过断路器（也叫熔断器）等一些列服务保护机制，保证服务调用者在调用异常服务时快速返回结果，避免大量同步等待。
服务网关：也称 API 网关，服务调用的唯一入口，可以在这个组件中实现用户鉴别权限，动态路由，灰度发布，负载限流等功能。
分布式配置中心: 将本地化的配置信息(properties, yml, yaml 等) 注册到配置中心，实现程序包在开发，测试，生产环境无差别，方便程序迁移。
comment: 灰度发布 是指部分功能的发布, 因为是微服务(可独立发布), 所以支持灰度发布.
技术选型
