1.基础知识

什么是微服务架构

简单说，微服务是系统架构上的一种设计风格，它的主指是将一个原本独立的系统拆分成多个小型服务，这些小型服务在各自的进程中运行，服务与服务之间通过HTTP的RESTful API进行通信。比如:一个商城，可以将购买流程拆分成->登陆，选择商品，下单，商品发货，订单完成等多个服务。被拆分的每个服务都围绕系统中的某一项或者耦合度较高的业务来构建的，并且每个服务都维护着自身的数据存储，业务开发，测试以及独立的部署机制。有了轻量级的通信协议做基础所以每个服务可以用不同的语言开发。

微服务和分布式的区别：分布式是将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互。区别分布式的方式是根据不同机器不同业务。微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，也可以是同一个服务器。

与单体系统的区别

在传统的系统架构中，一个系统大致分为三部分：数据库，服务端，前端；为了应对不同的业务我们将业务分为不同的业务模块，同时随着移动端设备的进步，前端展示形式已经不局限于web形式这对于后端向前端接口的支持需要更多的接口模块；在加上越来越多的业务需求使得单体应用越来越臃肿。这个时候单体应用的问题就凸显出来：
1.由于单体系统部署在一个进程，往往我们修改了一个很小的功能 然后部署上线这个时候就会影响其他业务模块。
2.由于单体这些模块的使用场景、并发量、消耗的资源类型各不相同但是对资源的利用又互相影响，使得我们对各个业务模块的容量很难给出较为准确的评估，使得维护成本变大且越来越难以控制。

如何实施微服务

微服务架构存在的问题：
1运维难度提升
2.接口的一致性
3.分布式的复杂性,比如延迟、分布式事物、异步消息等

微服务架构的9大特性
1.服务组件化：组件，是一个可以单独更换和升级的单元，独立且不影响其他单元。在微服务中我们需要对服务进行组件化分解。
2.按业务组织团队：面对大型项目，对于微服务团队的拆分建议按照业务线进行拆分。
3.做“产品”的态度：在实施微服务架构的团队中，每个小团队都应该以做产品的方式，对其产品整个生命周期负责。
4.智能断点与哑管道：在微服务架构中 通常使用两种通信方式：1.HTTPd RESTful API 或轻量级的消息发送协议 2.通过在轻量级消息总线上传递消息，类似Rabbit MQ等一些提供可靠异步交换的中间件。
5.去中心化治理：集中化的架构通常在技术平台都会定制统一的标准，在微服务中，各个组件都能针对不同的业务选择不同的技术平台。
6.去中心化管理数据：在实施微服务架构时，都希望每个服务管理其自有的数据库，这就是数据库管理的去中心化。但是不同的数据存储在不同的数据库实例中，数据一致性就会有很大问题。分布式事物的实现难度很大，所以在微服务架构中我们更强调服务之间"无事物"的调用，至于数据一致性，只要求数据在最后的处理状态是一致的即可。
7.基础设施自动化：自动化测试、自动化部署
8.容错设计：比如B调用出现故障的C C没有数据返回导致B挂起，而如果整个操作是由A发起去调用B让B调用C，这样一层层的调用　其中某层服务发生故障就会导致故障蔓延。所以在微服务中快速检测出故障并自动恢复是需要考虑的。通常我们希望每个服务中实现监控和日志记录的组件，服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等。
９.演进式设计：在初期使用单系统，随着系统的发展或者业务需要将一些经常变动或是有一定时间效应的内容进行微服务处理，并逐渐将原来系统中多变的模块逐渐拆分处理，而稳定的模块就形成一个核心微服务存在。