微服务基础知识

一、论微服务架构与单体架构

• 前言
• 一、什么是单体架构？
• • • 单体架构的优点：
    • 单体架构的缺点：
• 二、什么是微服务架构
• • • 微服务架构的优点：
  • 总结

---

前言

微服务架构是目前开发较为热门的技术点。本章内容简单介绍微服务与单体架构的概念及区别，帮助新手开发者建立初级概念，为后续SpringCloud Alibaba的学习奠定基础

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、什么是单体架构？

单体架构就像是一个盒子，所有的东西都放在这个盒子里。

一个包（war、jar）就能包含所有功能的应用。

单体架构的优点：

• 架构简单
• 开发 测试 部署方便

单体架构的缺点：

• 代码结构复杂
• 部署麻烦（全量部署 ，风险较高。）
• 很难扩展（内部有不同的需求，但都捆绑在一起，无法扩展。）
• 阻碍技术升级（有了更合适的技术，却干不动，代码紧耦合）

二、什么是微服务架构

微服务架构就好像一个柜子，所有的东西都分门别类的存放。

一系列独立的微服务构成整个系统，一个微服务只关注某个特定功能，可以单独维护。

微服务架构的优点：

• 易于开发维护：
  每个服务业务功能单一，开发和维护简单，体积小，启动快。
• 局部部署容易
  独立的服务可以单独部署，不影响其他服务。
• 易于扩展
  可以根据每个服务的特性进行有针对性的扩展。
• 易于技术升级：
  某个服务升级的新技术时，可以快速改造，不影响其他服务。

总结

重难点：

1. 单体架构的结构和特点
2. 单体架构的优缺点
3. 微服务架构的结构特点
4. 微服务架构的优缺点

 

另一篇基础知识

为什么要用微服务？

随着业务扩展、人员增长，单体式应用有以下问题：

1. 团队协作效率低下
2. 部署发布慢
3. 业务之间耦合度高，可用性差

微服务的好处

1. 独立部署
2. 独立维护
3. 业务低耦合

单体应用拆分方式

1、纵向拆分是从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。

2、横向拆分是从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。

拆分前需要思考的

1、用什么协议通讯
2、如何发布订阅
3、如何监控
4、服务如何治理
5、故障如何定位

一次正常的服务调用

1、【服务注册】首先服务提供者向注册中心注册服务，声明自己能够提供哪些服务以及服务的地址是什么，完成服务发布。
2、【可用服务查询】接下来服务消费者，从注册中心查询所需要调用服务的地址，
3、【调用，序列化和反序列化】调用方以约定的通信协议向服务提供者发起请求，得到请求结果后再按照约定的协议解析结果。

依赖的基础组件：

1. 服务描述：常用的服务描述方式包括 RESTful API、XML 配置以及 IDL 文件三种。
2. 注册中心：解决服务的发布和订阅，工作流程如下：
   • 服务提供者在启动时，根据服务发布文件中配置的发布信息向注册中心注册自己的服务。
   • 服务消费者在启动时，根据消费者配置文件中配置的服务信息向注册中心订阅自己所需要的服务。
   • 注册中心返回服务提供者地址列表给服务消费者。
   • 当服务提供者发生变化，注册中心将变更通知给服务消费者。
3. 服务框架
4. 服务监控
   • 指标收集
   • 数据处理
   • 数据展示
5. 服务追踪
   • 首次调用生成requestId
   • 每次调用继续传输requestId
6. 服务治理
   • 单点故障
   • 单idc故障
   • 依赖服务不可用

数据序列化和反序列化

1. 常用的序列化方式分为两类：文本类如 XML/JSON 等，二进制类如 PB/Thrift 等
2. 选型：
   • 数据结构丰富度
   • 跨语言特性
   • 性能：主要看两点，一个是序列化后的压缩比，一个是序列化的速度。以常用的 PB 序列化和 JSON 序列化协议为例来对比分析，PB 序列化的压缩比和速度都要比 JSON 序列化高很多，所以对性能和存储空间要求比较高的系统选用 PB 序列化更合适；而 JSON 序列化虽然性能要差一些，但可读性更好，更适合对外部提供服务。
     Proto Buf https://www.ibm.com/developerworks/cn/linux/l-cn-gpb/index.html

数据监控：

• 监控对象：
  • 客户端监控
  • 接口监控
  • 资源监控
  • 基础监控
• 监控指标：
  • 请求量(QPS)
  • 响应时间 TP90 TP99 TP 999
  • 错误率
• 监控纬度
  • 全局纬度
  • 分机房纬度
  • 单机纬度
  • 时间纬度
  • 核心纬度

服务治理有哪些手段：

• 节点管理：
  • 注册中心主动摘除
  • 服务消费者摘除机制
• 负载均衡
  • 随机算法
  • 轮训算法
  • 最少活跃调用算法
  • 一致性hash算法
• 路由规则：
  • 灰度发布
  • 多IDC访问问题
  • 配置方案：
• 服务容错的几个手段：
  • FailOver
  • FailBack
  • FailCache
  • FailFast

注册中心选型：

选型基本要求：

1. 高可用
   • 多IDC部署
   • 集群部署

2.数据一致性：多数据中心数据保持一致

CAP 理论：即同时满足一致性、可用性、分区容错性这三者是不可能的，其中 C（Consistency）代表一致性，A（Availability）代表可用性，P（Partition Tolerance）代表分区容错性。

CP 型注册中心，牺牲可用性来保证数据强一致性，最典型的例子就是 ZooKeeper，etcd，Consul 了。ZooKeeper 集群内只有一个 Leader，而且在 Leader 无法使用的时候通过 Paxos 算法选举出一个新的 Leader。这个 Leader 的目的就是保证写信息的时候只向这个 Leader 写入，Leader 会同步信息到 Followers，这个过程就可以保证数据的强一致性。但如果多个 ZooKeeper 之间网络出现问题，造成出现多个 Leader，发生脑裂的话，注册中心就不可用了。而 etcd 和 Consul 集群内都是通过 raft 协议来保证强一致性，如果出现脑裂的话， 注册中心也不可用。

AP 型注册中心，牺牲一致性来保证可用性，最典型的例子就是 Eureka 了。对比下 Zookeeper，Eureka 不用选举一个 Leader，每个 Eureka 服务器单独保存服务注册地址，因此有可能出现数据信息不一致的情况。但是当网络出现问题的时候，每台服务器都可以完成独立的服务。

 

=============================================================================================================================

二、微服务入门

微服务入门这一篇就够了

开篇

刚开始进入软件行业时还是单体应用的时代，前后端分离的概念都还没普及，开发的时候需要花大量的时间在“强大”的JSP上面，那时候SOA已经算是新技术了。现在，微服务已经大行其道，有哪个互联网产品不说自己是微服务架构呢？

但是，对于微服务的理解每个人都不太一样，这篇文章主要是聊一聊我对微服务的理解以及如何搭建经典的微服务架构，目的是梳理一下自己的一些想法，如果存在不同看法的欢迎指正！

什么是微服务

首先，什么是微服务呢？

单体应用

相对的，要理解什么是微服务，那么可以先理解什么是单体应用，在没有提出微服务的概念的“远古”年代，一个软件应用，往往会将应用所有功能都开发和打包在一起，那时候的一个B/S应用架构往往是这样的：

B/S

但是，当用户访问量变大导致一台服务器无法支撑时怎么办呢？加服务器加负载均衡，架构就变成这样了：

B/S+负载均衡

后面发现把静态文件独立出来，通过CDN等手段进行加速，可以提升应用的整体相应，单体应用的架构就变成：

B/S+前后端分离

上面3中架构都还是单体应用，只是在部署方面进行了优化，所以避免不了单体应用的根本的缺点：

• 代码臃肿，应用启动时间长；（代码超过1G的项目都有！）
• 回归测试周期长，修复一个小小bug可能都需要对所有关键业务进行回归测试。
• 应用容错性差，某个小小功能的程序错误可能导致整个系统宕机；
• 伸缩困难，单体应用扩展性能时只能整个应用进行扩展，造成计算资源浪费。
• 开发协作困难，一个大型应用系统，可能几十个甚至上百个开发人员，大家都在维护一套代码的话，代码merge复杂度急剧增加。

微服务

我认为任何技术的演进都是有迹可循的，任何新技术的出现都是为了解决原有技术无法解决的需求，所以，微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。

在微服务架构之前还有一个概念：SOA（Service-Oriented Architecture）-面向服务的体系架构。我认为的SOA只是一个架构模型的方法论，并不是一个明确而严谨的架构标准，只是后面很多人将SOA与The Open Group的SOA参考模型等同了，认为严格按照TOG-SOA标准的才算真正的SOA架构。SOA就已经提出的面向服务的架构思想，所以微服务应该算是SOA的一种演进吧。

撇开架构先不说，什么样的服务才算微服务呢？

• 单一职责的。一个微服务应该都是单一职责的，这才是“微”的体现，一个微服务解决一个业务问题（注意是一个业务问题而不是一个接口）。
• 面向服务的。将自己的业务能力封装并对外提供服务，这是继承SOA的核心思想，一个微服务本身也可能使用到其它微服务的能力。
  我觉得满足以上两点就可以认为典型的微服务。

微服务典型架构

微服务架构，核心是为了解决应用微服务化之后的服务治理问题。

应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件：服务注册中心，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：

服务注册中心

解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件：配置中心，微服务架构就变成下面这样了：

配置中心

以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：

典型微服务架构

上面是一个典型的微服务架构，当然微服务的服务治理还涉及很多内容，比如：

• 通过熔断、限流等机制保证高可用；
• 微服务之间调用的负载均衡；
• 分布式事务（2PC、3PC、TCC、LCN等）；
• 服务调用链跟踪等等。

微服务框架

目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo（或者DubboX），但是Dubbo那两年的停更严重打击了开发人员对它的信心，Spring Cloud已经逐渐成为主流，比较两个框架的优劣势的文章在网上有很多，这里就不重复了，选择什么框架还是按业务需求来吧，业务框架决定技术框架。
Spring Cloud全家桶提供了各种各样的组件，基本可以覆盖微服务的服务治理的方方面面，以下列出了Spring Cloud一些常用组件：

 

==================================================================================================================================

三、为何要使用微服务架构:

单一架构模式在项目初期的时候开发,测试,部署方便,但是随着项目逐步开发,项目工程会
很大,最终互相之间会有繁琐的jar包
1.不再适用于敏捷开发,任何开发人员都不能完全理解,在修复漏洞和添加新功能时
候变得复杂
2.项目模块越大,启动越慢,很小的改动也需要重新部署整个项目
3.任何模块的漏洞,都会降低系统的可靠性
4.如果想整体使用新的技术,新的框架,那是不可能的
如果采用微服务,解决了单一系统的复杂性,主要有以下优点
1.可采用敏捷开发模式,选择合适的技术
2.每一个微服务是独立部署的,可以快速迭代部署
3.一些需要负载均衡的服务可以使用ngix同一反向代理分发请求,这样不需要整个
系统负载均衡了

 

有微服务前，我们是怎么做的呢？我们可能是单体服务，可能是http远程调用，但都有各种缺陷。
比如，单体服务较为臃肿，业务变更频繁整体服务都会被波及；http远程调用的方式有点微服务的感觉，但是多个服务的路由都需要较为冗杂的代码来完成。
有了微服务这个概念以及相应解决方案后，上述的问题基本都能解决。可以笼统的讲：微服务方案，就是提供一套完整的技术组件来支撑整个微服务架构。
比如：路由下游服务的组件是注册中心和Ribbon；httpclient的组件是feign 或者dubbo; 服务限流或者降级是 hystrix 等等。

 

==================================================================================================================================

四、应用案例