WHAT：什么是微服务？
微服务是系统架构上的一种设计风格，主旨是将一个原本独立的系统拆分成多个小型服务，
这些小型服务都在各自独立的进程中运行，服务之间通过基于http的RESTful API进行通信协作。
WHY：为什么要用微服务？解决了啥问题？
由于轻量级的通信协作，所以微服务可以用不同的语言来编写。
传统单体系统架构，会随着业务需求的增加而不断增加业务模块；
同时移动端设备要求前端展现也不仅仅陷于WEB，需要后端向前端提供更多的接口模块。
这样使得单体系统架构变得臃肿
单体系统部署在一个进程内，如果修改功能，在部署上线时候会影响其他功能运行。
单体系统功能模块之间，对于资源的利用相互影响，使对各个业务模块的系统容量很难给出准确评估。
初期开发简单，但是后期维护成本大。。。
微服务就是解决上述问题而诞生的。
可以将不同功能模块拆分成多个不同服务，这些服务又都可以独立部署和扩展。
每个服务都运行在自己的进程内，在部署上有稳固的边界，每个服务的更新都不会影响其他服务的运行。
由于是独立部署，对每个服务我们可以更准确的评估性能容量。
通过配合服务间的协作量程可以更容易发现系统的瓶颈。给出较为准确的系统级性能容量评估
HOW：怎么实现？
这些小型服务都围绕着系统中的某一项或一些耦合较高的业务功能进行构建，
每个小服务否维护着自身的数据存储、业务开发、自动化测试案例，以及独立部署机制。
如何实施微服务（微服务引发的单体没有的问题）
运维： 需要维护的进程数变多，需要更多的自动化。要求运维有一定的开发能力
接口一致性：
业务逻辑上的依赖还是一样的。从单体中剥离，编程了服务之间的通信依赖。
如果对接口进行修改，交互方也需要进行协调修改，来保证接口的调用。需要更完善的接口和版本管理。或是严格遵循开闭原则。
开闭原则：
遵循开闭原则设计出的模块具有两个主要特征：[1]
（1）对于扩展是开放的（Open for extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，我们可以改变模块的功能。
（2）对于修改是关闭的（Closed for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者.EXE文件，都无需改动。
分布式的复杂性：
拆分后的各个微服务都是独立部署并运行在各自进程，只能通过通信来协作。
分布式环境的问题都是微服务架构的问题。。。网络延迟，分布式事务，异步消息等。。。
但是，瑕不掩瑜。。。敏捷开发 和 自动化部署 是微服务很重要的优点。
微服务架构9大特性
1、服务组件化：对服务进行热插拔组件化分解。。。
2、按业务组织团队：每个微服务都是对特定业务的宽或全栈实现。。。对微服务团队需按照业务线拆分
3、做“产品”的态度：每个小团队都应该把自己的模块看做一个产品，对整个生命周期负责。
4、智能端点与哑管道：仅仅将原本同一个进程中的方法调用改成RPC方式，会导致微服务之间产生过于频繁的通信，反而使得系统表现糟糕，应该采用更粗粒度的通信协议。。。
通常采用下面两种：
①、HTTP的RESTful API 或 轻量级的消息发送协议，实现信息传递和服务调用触发
②、在轻量级消息总线上传递消息，RabbitMQ等可提供可靠异步交换的中间件。。。
极度强调性能的时候， 可以采用二进制消息发送协议，入protobuf。
任然会呈现“
智能端点与哑管道”的特点，是为了在易读性和高效性之间取得平衡。。。一般只需要做到易读性就可以了。
5、去中心化治理：集中化架构治理方案会因为技术平台本身的（底层的）瓶颈出现短板。最终导致系统的瓶颈。 。。微服务架构，采用轻量级的契约定义接口，减少了服务队技术平台的敏感度。。。根据各组件（各服务）的不同业务特点选择不同技术平台。。。完美解决项目整体受限于某一个技术平台导致性能制约。
6、去中心化管理数据：让每一个服务管理自己的数据库，就是数据管理的去中心化。
举例： 将原数据库中的内容拆分到同平台其他数据库实例中（将原来的MySQL库中的表，拆分后存储到不同的MySQL实例中）。。。将一些具有特殊结构或业务特殊性的数据存储到一些其他技术的数据库实例中（日志存到MongoDB，用户登录信息存在Redis中）
****数据管理区中心化，优点：可有让数据管理更细致，可以采用合适的技术让数据存储和性能最优。
缺点：数据存储到不同库中，数据一致性问题接踵而至。。。分布式事务。。。
分布式事务实现难度大，所以在微服务架构中，服务之间强调“无事务”调用
*****对数据的一致性问题，只要求数据在最后的处理状态是一致的即可**********
*****若过程中出错，通过补偿机制处理，使数据达到最终一致********
7、基础设施自动化：云服务 + 容器技术 ， 使得基础设施运维变得简单。
实施微服务架构时候， 虽然数据库、服务的粒度虽然变小了。。。但是拆分的原因和数量也随之增加了。
运维需要关注的内容和，任务数量也成倍增加。。。
微服务架构中，从开始就必须构建一个“持续交付” 的运维平台来支撑整个实施过程。
持续交付平台，分为两大块内容：
自动化测试：测试需要有一定的编程能力。。。
自动化部署：减少重复操作，减少对多环境的配置管理。。。运维需要有一定编程能力
8、容错设计：
单体——一挂全挂！
微服务——由于微服务都是独立运行，可能出现部分故障，其余仍旧可以正常运行
为了不出现当前线程被调用服务出现故障挂起，导致调用其他直接或间接依赖该服务的线程都被挂起，导致故障蔓延。。。在微服务架构中，快速检测出故障源并尽可能自动恢复服务必须被设计和考虑到。。。
所以，要有在每个服务中实现监控和日志记录的组件，如服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘组件。。。
9、演进式设计：
上面我们需要考虑到 组件化、团队的业务线拆分、模块产品化：开发对每个模块的整个声明周期负责、解决智能端点和哑管道问题，需要采用更粗粒度的通信协议（需要在高效和易读之间权衡，一般选择易读；采用轻量级总线---MQ中间件等 或者 HTTP RESTful API进行消息通信）、数据库平行化拆分和特殊需求拆分（日志用MongoDB，用户登录信息用Redis；强调“无事务”调用，和调用失败之后的补偿机制）、运维关注点的转移（多任务管理+自动化能力）、微服务调用之间的容错机制（故障快速定位和自动恢复设计，需要在每个服务中添加仪表盘组件）。。。
架构需要以演进的方式构建系统。。。初期按照单体方式来设计和实施。
随着系统发展和业务需求增多，将经常变动 and 有时效性 的内容微服务化。。。
将原来单体系统中多变的模块拆分出来，最后留下稳定不太变动的模块作为核心微服务存在于整体架构中。。。