微服务基础学习

Microservices Architecture Pattern微服务架构模式的目的：将大型的复杂的长期运行的应用程序构建为一组相互配合的服务，每一个服务都可以很容易的进行局部改良。不是代码量小，而是业务逻辑上的概念，符合SRP原则的才叫微服务。

SRP原则：单一职责原则 Single Responsibility Principle

SOA：Service Oriented Architecture 面向服务架构
ESB：Enterprise Service Bus 企业服务总线：是SOA架构中的中心总线，设计图形应该是星形的，微服务是去中心化的分布式软件架构。

巨石型应用

巨石型应用：所有功能都部署在一个Web容器中运行的系统。
好处：IDE都是为开发单个应用设计的、容易测试——在本地就可以启动完整的系统、容易部署——直接打包为一个完整的包，拷贝到web容器的某个目录下即可运行。
坏处：要修改一个地方就要将整个应用重新部署；回归测试周期过长、编译时间长、开发效率低下等。

巨石型应用不利于更新技术框架。

应用的划分

应用的划分不是为了搞出一堆很小的服务，是为了解决巨石型应用在业务急剧增长的时候遇到的问题。

一般都是分为前端服务和后端服务。

学习怎么看 Scale Cube 或者画出 Scale Cube

优缺点

微服务架构的优点与缺点

1. 优点

每个服务足够内聚，足够小，代码容易理解、开发效率提高

服务之间可以独立部署，微服务架构让持续部署成为可能；

每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上；

容易扩大开发团队，可以针对每个服务（service）组件开发团队；

提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；

系统不会被长期限制在某个技术栈上。

2. 缺点

开发人员要处理分布式系统的复杂性；开发人员要设计服务之间的通信机制，对于需要多个后端服务的user case，要在没有分布式事务的情况下实现代码非常困难；涉及多个服务直接的自动化测试也具备相当的挑战性；

服务管理的复杂性，在生产环境中要管理多个不同的服务的实例，这意味着开发团队需要全局统筹（PS：现在docker的出现适合解决这个问题）

应用微服务架构的时机如何把握？对于业务还没有理清楚、业务数据和处理能力还没有开始爆发式增长之前的创业公司，不需要考虑微服务架构模式，这时候最重要的是快速开发、快速部署、快速试错。

1. 微服务架构的通信机制

（1）客户端与服务器之间的通信
客户端可以向micro service发起RESTful HTTP请求，但是会有这种情况发生：客户端为了完成一个业务逻辑，需要发起多个HTTP请求，从而造成系统的吞吐率下降，再加上无线网络的延迟高，会严重影响客户端的用户体验。
所以，我们一般会加上API gateway

2.内部服务之间的通信

内部服务之间的通信方式有两种：基于HTTP协议的同步机制（REST、RPC）；基于消息队列的异步消息处理机制（AMQP-based message broker）

Dubbo是阿里巴巴开源的分布式服务框架，属于同步调用，当一个系统的服务太多时，需要一个注册中心来处理服务发现问题，例如使用ZooKeeper这类配置服务器进行服务的地址管理：服务的发布者要向ZooKeeper发送请求，将自己的服务地址和函数名称等信息记录在案；服务的调用者要知道服务的相关信息，具体的机器地址在ZooKeeper查询得到。这种同步的调用机制足够直观简单，只是没有“订阅——推送”机制。

AMQP-based的代表系统是kafka、RabbitMQ等。这类分布式消息处理系统将订阅者和消费者解耦合，消息的生产者不需要消费者一直在线；消息的生产者只需要把消息发送给消息代理，因此也不需要服务发现机制。
两种通信机制都有各自的优点和缺点，实际中的系统经常包含两种通信机制。例如，在分布式数据管理中，就需要同时用到同步HTTP机制和异步消息处理机制。

分布式数据管理

1. 处理读请求

以信用卡额度的管理为例。

A.每一次的Order Service都要通过RPC向CustomerService请求数据，那么获取的数据一定准确，但是多次RPC调用，而且Customer Service必须保持在线。

B.在Order Service中存储一份数据副本，并且当Customer Service中的数据发生变化的时候，要及时更新Order Service中的数据。

2.处理更新请求

A.分布式事务：Distributed transactions
简单来说，就是要更新CustomerService中的数据，其他Service中的数据也要一致的更新，要么都更新，要么都不更新。
缺点：所有服务都必须在线，而且REST和NoSQL数据库都不支持事务。

B 基于事件的异步更新 Event-driven asynchronous updates
例如，当Customer Service中数据发生改变的时候，他对外发布一个事件到“message broker”（消息代理人），其他Service可以选择订阅这个事件or not，订阅了该事件的Service收到提示之后，就更新数据。