微服务架构精讲-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_44637905/article/details/100978958

微服务架构入门

微服务架构思想
（微服务就是分布式演变出来的）

1. 行业软件分类概述

传统软件： 主要面向的群体是公司内部的员工一般这种软件都是承包给外包公司来做

(公司员工发家概率小、机遇少、稳定、技术一般要求不高，落后 --> 码农位于这种公司竞争力属于逐年下降…但是比较适合初入行的人员)

OA(办公自动化软件)
ERP(企业资源计划系统大型系统可能拥有很多子系统)
CRM(客户关系管理系统)
CMS(内容管理系统) -> App信息管理平台、网站后台管理… 超市订单系统…
…

以前大多数情况下，传统软件是架设在局域网内的。传统软件也开始逐渐向互联网软件演变。

例如：悟空CRM、通达OA…

**互联网软件(非传统软件)：**主要面向的群体是广大互联网用户一般是公司自研产品

(公司员工发家概率大、机遇与风险并存、待遇比较高、对新型技术追逐比较高、需求变换频繁…竞争力比较大，出来之后也是有好履历…)

电商类：淘宝、天猫、京东、唯品会、拼多多、亚马逊…
生活旅游类：爱旅行、携程、途牛、飞猪、马蜂窝…
游戏类：
影音类：爱奇艺、优酷…
直播类：花椒、虎牙、斗鱼、企鹅电竞…
出行类：滴滴、美团打车…
…

2. 软件架构概述

传统软件：单体式架构

一个项目包含着前端和后端… 例如：信息管理平台、超市订单管理系统…
项目迭代不灵活
项目组责任、权限不清
项目并发配置不灵活

互联网软件：分布式架构

分布式架构的演变就是由于互联网软件对软件的性能、和扩展性要求比较高，但是单体式架构性能比较差，扩展性也差。例如：单个模块的性能提升、宕机后的容错、协同开发的难度…

多个项目，项目前端和后端可能不在一起，后端可能按照业务进行了单元划分… 例如：爱旅行(单体分布式)
爱旅行不是完整的分布式，项目之前业务拆分不完整，主业务需要订单模块需要自己写支付业务需要订单模块需要自己写… 分布式单元之间没有通信，假设主业务需要支付业务内容，爱旅行需要将支付业务打包作为依赖给主业务，未来如果支付业务变更了内容，则主业务还要重新进行依赖。
完整的分布式应该是各个单元独立的，业务代码上无依赖。
项目复杂度降低
团队界限明确
扩展灵活

比较项	传统软件行业	互联网软件行业
面向用户	企业内部用户	互联网线上用户
用户量	小	庞大
并发考虑	少/几乎不用考虑	必须考虑
项目代码量	少	多
数据量	小	海量数据
架构方式	《单体式架构》	《分布式架构》
开发团队	单个团队	多个团队
部署	单个服务器	集群服务器
运维复杂度	低	高

3. 微服务概述

分布式-微服务架构

大公司们发现了单体式架构缺陷之后开始进行分布式架构开发。

SOA：面向服务编程。在分布式架构开发中，大公司们已经开始将各个业务模块作为单独的服务单元来进行开发了。例如：酒店业务、订单业务、支付业务…

没有一个统一的规则，也没有协调的组成。业务之间的通信管理滞后。

Martin Fowler提出了微服务(Micro Service)它是指一种软件架构风格。一个大型的系统可以由多个微服务组成，每个微服务是被独立部署，独立完成自己的任务单元，微服务之间是通过API方式进行通信调用，是松耦合的。

Service Mesh又译作“服务网格”，作为服务间通信的基础设施层。Willian Morgan（Linkerd的CEO）如下定义Service Mesh。Service Mesh 是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，Service Mesh 保证请求可以在这些拓扑中可靠地穿梭。在实际应用当中，Service Mesh 通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但应用程序不需要知道它们的存在。

4. 微服务相关术语(组成元素)

要保证这么一套微服务架构能成功运行起来，我们起码需要以下这些微服务的基础组件：

服务节点 按照业务单元划分
- Consumer 服务消费者：订单服务中需要消费其他服务的内容会归类到消费者模块 controller
- Provider 服务提供者：订单服务中可以提供给其他服务的内容会归类到提供者模块 service…
服务注册(注册中心 Registry)

部署了一个微服务节点，得让调用者知道啊，当微服务节点有增加或减少的时候，也得让调用者及时知晓啊。这些问题都是通过“服务注册”组件来实现的，服务提供者将自己的服务地址等信息登记到“服务注册”组件中，调用者需要的时候，每次都先去查询“服务注册”即可。免去人工维护微服务节点的信息同步问题。
服务网关(Gateway)

是指提供给外部系统调用的是统一网关。主要做安全和权限控制等。
配置中心(Config Server)

微服务的配置中心是用来统一管理所有微服务节点的配置信息的。因为同一个程序可能要适用于多个环境，所以在微服务实践中要尽量做到程序与配置分离，将配置进行集中管理。包括微服务节点信息、程序运行时配置、变量配置、数据源配置、日志配置、版本配置等。
服务框架(微服务解决方案、RPC、RESTFUL)

是指用来规范各个微服务节点之间通信标准的。服务间通信采用什么协议、数据是如何传输的、数据格式是什么样的。有了这个统一的“服务框架”就能保证各个微服务节点之间高效率的协同。
服务监控

微服务运行起来之后，为了能够监控节点的健康情况，保障节点的高可行，需要对各个服务节点进行收集数据指标、然后对数据进行实时处理和分析，形成监控报表和预警。
服务追踪

一旦使用了微服务架构，那么当有请求过来时，就会经过多个微服务节点的处理，形成了一个调用链。为了进行问题追踪和故障的定位，需要对请求的完整调用链进行记录。

这里的服务追踪与上面的服务监控是不同维度的，一个是全局的，一个是微观的，发挥的作用也不一样。
服务治理

就是指需要通过准备一些策略和方案，来保障整个微服务架构在生产环境遇到极端情况下也能正常提供服务的措施。比如熔断、限流、隔离等等。

当然，上述只是一个微服务架构最为核心的基础组件，一旦微服务体系过大，例如有几十上百个微服务节点，那么开发、维护、测试的成本就会非常大。因此一般还会引入自动化部署和自动化测试来提高协同效率。

微服务注意事项：

大家都在宣扬「微服务」多么多么的好，例如：易扩展、松耦合、服务简单、独立开发、易维护、轻量级等等。虽然这些优势也是事实，但是「微服务」带来的问题也很多，尤其是对于刚入门的团队而言，应用微服务后，趟坑真的可以趟到你崩溃。下面就普及一些常见的问题来给大家打个预防针：

不是所有项目都适用微服务

有些项目规模还比较小，或者项目才刚立项启动，也只有三四个人负责开发维护，这时候是不建议一上来就搞微服务架构的。这种情况下搞微服务，不仅是“杀鸡用牛刀”，而且还无谓的增加了项目的复杂度，本身一个单体结构就可以搞定的事情，非得拆分N多节点，人员又不足以支撑这么多节点的开发维护，这完全是自找苦吃。反而是等项目成熟了、规模大了之后，再开始慢慢将原有结构拆为微服务才是正确的做法。
不要拆分过多过细的服务

即使项目经过评估后适合拆为微服务架构，但也不要过度拆解。有的团队喜欢将项目拆成很细很细的颗粒，最后把项目搞的特别复杂，整个团队都陷进去了。

拆分服务的颗粒度应该根据业务发展和团队现状综合去考虑。这里可以参考一个很火的理论「康威定律」。什么样的团队，就产生什么样的架构，微服务拆分的颗粒度是需要和团队结构相匹配的。当你着手拆微服务的时候，得先评估一下团队人员和素质，一般在开发期，2-3个人开发一个服务是合理的，在维护期，1个人维护2-3个服务也是合理的。

如果拆分过细，开发人员跟不上，会严重降低大家的工作效率。并且过细的服务，会导致一个请求的调用链条很长，不仅会影响请求的响应时间，也会对线上问题排查带来增加难度。
没有DevOps就不要急于微服务

一个稳定的微服务架构，是需要持续集成、自动化部署、自动化测试、健全的监控体系来保障的。如果团队还不具备DevOps，这些基础的建设都没有做好，一上来就搞微服务的话，就会导致实施过程中问题百出，微服务的优势不能发挥。

微服务架构设计原则：

围绕业务切分
单一职责
谁创建，谁负责

5. 微服务常见解决方案(MicroService)

基于Dubbo的微服务体系(组装机) 2012年阿里巴巴开源的后来闭源了 (当当自己维护 dubbox) 2017年捐给了apache基金会 2019年孵化完成。
- Dubbo只是一个RPC框架服务节点之间通信用的
- Zookeeper来实现注册中心
SpringCloud微服务体系(一体机/品牌机)
- 它是基于Netflix开源的微服务基础组件来实现的一套微服务解决方案

RPC：非常类似于本地代码调用的一种服务调用。

为什么要使用RPC？

RPC（remote procedure call）是指远程过程调用，比如两台服务器A和B，A服务器上部署一个应用，B服务器上部署一个应用，A服务器上的应用想调用B服务器上的应用提供的接口，由于不在一个内存空间，不能直接调用，所以需要通过网络来表达调用的语义和传达调用的数据。

public class Controller{ 

	@Resource
	private Service service; // 位于本地依赖的库中的

}

public class Controller{ // 订单的消费者

	// 像调用本地服务一样调用远程的其他服务节点
	private Service service; // 商品的服务提供者  

}

**RESTFUL风格请求：**利用HTTP协议来进行请求

public class Controller{
	
	@Resource
	private Serive service;
	
	@RequestMapping()
	public void xxx(){
		sevice.xxx();
	}

}

public interface Service{
	
	@RequestMapping()
	public void xxxx();

}

6. 双十一抢购/秒杀系统(模块)

6.1 项目介绍

模仿天猫双十一、京东618实现的一个秒杀项目。此项目功能也是很多售货类平台的刚需，可以应用很多场景。

千万记住它并不是一个完整的项目，而仅仅是一个大型项目中的一个模块，一个子系统。

在这个秒杀项目中会涉及到的问题如下：(要学习的技术点)

**高并发：**同一时间大量的用户进行请求多线程
- 承受住高并发负载能力进行提升
- (项目性能的优化)
  - 前端：CSS等静态资源的渲染可以使用CDN(加速)或者浏览器缓存
  - 服务器：考虑集群(负载均衡) 调整服务器的参数、提升服务器的硬件缓存技术… 消息中间件…
  - 项目架构：分布式微服务架构
  - 数据库：数据库集群、主从备份、读写分离、水平拆分、垂直拆分…
单用户多次操作： 用户担心自己抢不到会下意识多次进行点击
- 前端：可以进行锁定
- 后端：考虑消息的觅等性（觅等性：多次操作还是一个结果）利用标识来进行识别用户是否已经抢购过
**抢购的顺序：**第一个点击抢购的用户应该是第一个抢到的但是因为多线程导致请求之间处于争抢形式，无法保证顺序
- 消息队列(MessageQueue)