初识微服务

一.单体架构和微服务架构的比较

1.单体架构的优点和不足

单体架构的优点：在项目的初期便于开发、便于测试、便于部署

单体架构的不足：

• 复杂性高-代码难以理解，难以修改和重构
• 交付效率低-项目总体部署耗时长、难以定位问题、影响范围广、风险大、发布频次低
• 伸缩性差-单体只能按总体进行横向扩展，没法分模块垂直扩展；IO密集型模块（日志收集）和cpu密集型模块（图片压缩、加解密）没法独立扩容和升级
• 可靠性差-一个bug有可能引发整个应用的崩溃
• 受技术栈限制，团队只能使用同一个语言和框架

什么是横向扩展和垂直扩展？

1）横向扩展 也叫 水平扩展，用更多的节点支撑更大量的请求。 如成千上万的蚂蚁完成一项搬运工做

2）纵向扩展 又叫 垂直扩展，扩展一个点的能力支撑更大的请求。如利用1我的的能力，如蜘蛛侠逼停火 

2.什么是微服务架构?

微服务架构自己来源于互联网的思路，所以组件对外发布的服务强调了采用HTTP Rest API的方式来进行。

将单体应用拆分红多个高内聚低耦合的小型服务，独立部署，能够采用不一样的语言以及存储，每一个小型服务运行在独立进程当中，服务间采用轻量级通讯机制，而非采用进程内调用的方式进行通讯。

3.微服务架构的优点

• 易于开发和维护-微服务相对小，易于理解，启动时间少，开发效率高
• 独立部署-一个微服务的修改不须要协调其余服务　　
• 伸缩性强-每一个服务均可以进行横向和纵向扩展；每一个服务均可以独立扩容
• 技术异构性-各个微服务可使用最适合该服务的技术

2、微服务所要解决的主要问题

1.服务的拆分

• 微服务拆分的原则-高内聚低耦合、服务粒度适中
• 拥有独立的数据库
• 微服务之间肯定服务边界

2.数据一致性

在微服务架构下，每一个服务对应一个数据库，这就出现了原来单体中对同一个库的操做变成了跨服务数据库的操做。

遇到有事务约束的场景，好比转帐汇款、订单状态和库存扣减，就从本地事务过渡到分布式事务来了。

 

在微服务中使用最终一致性来代替强一致性。

实现最终一致性有两种模式:

1）.用消息队列实现可靠性模式

2）.补偿模式-sagas模式

在微服务的初期尽可能粗粒度，将事务放在一个服务中。

这两种方式都须要写大量的代码，阿里巴巴提出的了分布式事务解决方案----GTS

 

3.服务通讯

• 通讯技术方案-RPCvsRESTvs异步消息

4.服务治理—服务注册与发现

• 服务注册中心
• 服务提供者
• 服务消费者

5.服务网关

它的定义相似于面向对象设计模式中的Facade模式，它的存在就像是整个微服务架构系统的门面同样，全部的外部客户端访问都须要通过它来进行调度和过滤。

由它来实现请求路由、负载均衡、校验过滤等功能，以及与服务治理框架的结合，请求转发的熔断机制、服务的聚合等。

• 身份认证、路由服务、流量控制、日志统计

若是咱们的微服务和终端通讯，势必要考虑身份认证，若是咱们的微服务都与每一个终端用户打交道，那么这些代码就须要拷贝多份，

而且植入到每一个微服务业务代码中，这就形成业务代码和身份认证代码耦合，下降代码的复用性。

在身份认证、路由服务等放在服务网关中，向业务代码中屏蔽这些网络边界的细节，使得业务服务专一于业务逻辑的开发。

• 为前端服务的后端

　　好比将多个服务的数据聚合在一块儿返回给前端

6.可靠性

在单体架构中，可能由于一个服务不可用致使整个系统不可用。微服务不会产生这种状况，一个微服务不可用时不会影响和它没有依赖关系的服务，

可是可能由于一个服务不可用致使上游服务线程服务夯死，故障进一步向上传播。

这个地方线程服务夯死是指的是服务不断占用资源，致使其余服务线程没法正常工做。

• 仓壁隔离

仓壁隔离：给每一个应用分配一个独立的线程池，而不是共享线程池，这样一个应用的故障不会拖累其余服务。

• 服务降级

服务降级：当服务不可用时，服务消费者应该对接口编写降级方法，

好比评论服务在获取用户服务的头像时，用户服务不可用，那么降级方法能够返回默认头像，或者缓存中的头像，

好比推荐服务不可用时，网关服务右边栏的页面使他为空，不展现任何信息。

• 服务熔断

熔断：是指服务不可用在必定的时间内达到必定的数量，自动关闭该服务的调用开关，直接调用降级逻辑，这样下降资源耗尽的风险

7.高可观察

• 健康检查、集中监控

微服务整个系统都须要在咱们的监控体系中，包括注册中心的监控、 服务进程的监控、流量的监控、日志的监控，状态的监控等 

将这些信息集中以图表的形式输出，方便查看问题。

• 日志聚合及检索

好比说在电商app中，咱们没法进行下单操做，在分布式服务架构中 ，日志是散落在多个服务上的，咱们若是说登陆每台服务器进行检索是很是低效的，这就须要咱们进行日志格式的标准化，并利用必定的手段将日志聚合起来进行检索查询，咱们须要将这些检索查询的组件放到共享库当中，或者代码脚手架进行提供，以方便咱们和业务代码进行解耦。

• 分布式追踪

在微服务场景中，一个客户端发起的请求要通过多个服务的调用，咱们不知道该请求经历哪些服务的调用，调用哪些服务出现了问题，每一个服务的输入输出是什么，这都给咱们定位问题带来的困难；除此以外若是一个请求耗时挺长，咱们不知道哪一个服务耗时最长，这就给咱们性能优化带来了困难。随着架构的演进，咱们须要知道服务之间的依赖关系，这就须要咱们的分布式追踪。

 

3、SOA和微服务的比较

• 技术栈

SOA：ESB、SOAP

微服务：轻量级MQ、REST、RPC

• 数据拆分

SOA：共享数据库

微服务：一服务一数据库

• 服务粒度

SOA：服务粒度比较粗，多个单体的组合

微服务:粒度更小的服务