什么是微服务

微服务架构就是把 个大系统按业务功能分解成多个职责单的小系统，并利用简单的方法使多个小系统相互协作，组合成 个大系统。

从单体应用说起
所有服务都相合在一应用中，当其中一个服务出现问题时，整个工程都需要重新发布，从而导致整体业务不能提供响应。
第一步切分
优点：业务通过进程间的服务进行相互调用，数据库之间没有稿合性，不会存在单点故障。
服务化所带来的问题
客户端如何访问这些服务？这些服务的调用情况？切分是否合理？是否安全？如果受到攻击应该如何应对？是否可以使用限流或者降级的方式来及时解决？应对这些问题， API网关是一个不错的解决方案。当有新的设备需要调用这些接口时，可以复用原有接口。

服务之间的相互调用，最简单的方式是通过 RPC 调用，传输 JSON 或者 XM ，双方定义好协议格式，通过报文 方式进行数据传输。
一般的分布式服务都有一个注册中心，自身提供管理控制台，可以对服务进行注册和查找，每个应用服务仍然存在着单点 题，当 个服务出现问题时 有可能导致连锁的反应，使整个系统瘫痪。这时需要除监控告警外的一种容错机制来保障整体服务的可运行性。

微服务与 SOA 的区别
相同点
1.需要 Registry ，实现动态的服务注册。
2.发现机制需要考虑分布式下面的事务 致性， CAP 原则下，两段式提交不能保证性能，事务补偿机制需要考虑。
3.同步调用还是异步消息传递，如何保证消息可靠性？ SOA ESB 来集成所有的消息。
4.都需要统 Gateway 来汇聚、编排接口，实现统 认证机制，对外提供 APP 使用的
RESTful 接口。
5.同样要关注如何再分布式下定位系统问题，如何做日志跟踪？就像电信领域做了十几年的信令跟踪的功能。

常见的微服务组件

服务注册
服务注册是 个记录当前可用的微服务实例的网络信息数据库，是服务发现机制的主要核心，服务注册表包含查询 API管理 API ，使用查询 API 获得可用服务的实例，使用管理 API实现注册、注销。
服务发现
服务调用方从服务注册中心找到自己需要调用的服务的地址。可以选择客户端服务发现，也可以选择服务端服务发现。
负载均衡
服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点，并且节点选择的工作对服务调用方来说是透明的。可以选择服务端的负载均衡，也可以选择客户端的负载均衡。
服务网关
服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。根据公司流量规模的大小网关可以是 一个，也可以是多个。
配置中心
将本地化的配置信息（ Properties XML YAML 等〉注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。配置部分可以单独使用高可用的分布式配置中心，确保一个配置服务出现问题时，其他服务也能够提供配置服务。
API 管理
以方便的形式编写及更新 API 文档，井以方便的形式供调用者查看和测试。通常需要加入版本控制的概念，以确保服务的不同版本在升级过程中都能够提供服务。

集成框架

微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组
件集成到统一的界面框架下，让用户能够在统一的界面中使用系统。

分布式事务

对于重要的业务，需要通过分布式事务技术 CTCC 、高可用消息服务、最大努力通知〉保
证数据的一致性。根据业务的不同，适当地牺牲一些数据的一致性要求，确保数据的最终一致
性。

调用链

记录完成 一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在
系统出锚时，可以方便地找到出错点。同时统计各个服务的调用次数，确保 较热的服务能够
被分配更多的资源。

常用的微服务框架

主流微服务框架（ Spring Cloud Dubbo 〕：

Dubbo

微服务化治理框架，致力于提供高性能、透明化的 RPC 远程服务调用方案和SOA 服务治理方案。

微服务架构设计模式

聚合器微服务设计模式
聚合器调用多个服务实现应用程序所需的功能，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务。

代理微服务设计模式
客户端并不聚合数据，但会根据业务需求的差别调用不 同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作 每个微服务都有自己独立的缓存和数据库系统，彼此独立。

链式微服务设计模式
服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信 所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会 直阻塞。

分支微服务设计模式
每个调用链分别调用自己的服务。当某个调用出现问题时，相互之间不会造成影响。

数据共享微服务设计模式
部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之存在强稠合关系时才可以。

异步消息传递微服务设计模式
虽然 REST 设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替阻REST 请求／响应