微服务架构讲解之开篇概述

最新推荐文章于 2022-02-03 14:33:57 发布

patriot_28

最新推荐文章于 2022-02-03 14:33:57 发布

阅读量626

点赞数

分类专栏：微服务架构

本文链接：https://blog.csdn.net/patriot_28/article/details/108743703

版权

微服务架构专栏收录该内容

2 篇文章 0 订阅

订阅专栏

由于微服务涉及的技术及相关框架、组件非常多，抽取其中任何一个东西都可以至少编成一大章节的内容，甚至可以编成一本书。本人没办法一下子全部讲解到位。为了让大家能更快第了解和掌握微服务，我将从这一篇开始逐步介绍微服务相关的东西。后面将会不断发布以“微服务架构讲解之”开头的微服务系列博文。当然，由于本人水平有限，错误疏漏之处欢迎大家斧正。

什么是微服务

简单地说，微服务架构就是把一个大的单体应用按业务边界拆分成一组微小的高内聚低耦合的服务组件，每个微服务组件单独运行，各组件之间通过HTTP这样的轻量级协议，按照REST风格（不限于）用JSON格式进行数据交换，相互协作。这些组件采用自动化部署机制，可以使用不用的语言开发，使用不同的技术进行数据存储。
微服务体现去中心化、天然分布式，是中台战略（中台并不是微服务，中台是一种企业治理思想和方法论，微服务是技术架构方式）落地到IT系统的具体实现方式的技术架构，用来解决企业业务快速发展与创新时面临的系统弹性可扩展、敏捷迭代、技术驱动业务创新等难题。
微服务架构具有以下特征：

应用程序逻辑分解为具有明确定义了职责范围的细粒度组件，这些组件互相协调提供解决方案。
每个组件都有一个小的职责领域，并且完全独立部署。微服务应该对业务领域的单个部分负责。此外，一个微服务应该可以跨多个应用程序复用。
微服务通信基于一些基本的原则，并采用HTTP和JSON这样的轻量级通信协议，在服务消费者和服务提供者之间进行数据交换。
服务的底层采用什么技术并没有什么影响，因为应用程序始终使用技术中立的协议（JSON是最常见的）进行通信。这意味着构建在微服务之上的应用程序能够使用多种编程语言和技术进行构建。
微服务利用其小、独立和分布式的性质，使组织拥有明确责任领域的小型开发团队。这些团队可能为同一个目标，如交付一个应用程序，但是每个团队只负责他们在做的服务。
【单体应用架构】

【微服务架构】

为什么要用微服务，有什么挑战

微服务架构的优点

每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。微服务能使用不同的语言开发。
微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, bamboo 。一个团队的新成员能够更快投入生产。
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。微服务允许你利用融合最新技术。
微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。微服务能够即时被要求扩展。微服务能部署中低端配置的服务器上。
易于和第三方集成。每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

微服务架构的挑战

以下挑战基本对应后面介绍的核心组件。

单个微服务代码量小，易修改和维护。但是，系统复杂度的总量是不变的，每个服务代码少了，但服务的个数肯定就多了。就跟拼图游戏一样，切的越碎，越难拼出整幅图。一个系统被拆分成零碎的微服务，最后要集成为一个完整的系统，其复杂度肯定比大块的功能集成要高很多。
单个微服务数据独立，可独立部署和运行。虽然微服务本身是可以独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到要对外通信，当微服务的数量达到一定量级的时候，如何提供一个高效的集群通信机制成为一个问题。
单个微服务拥有自己的进程，进程本身就可以动态的启停，为无缝升级的打好了基础，但谁来启动和停止进程，什么时机，选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的，而是需要背后强大的版本管理和部署能力。
多个相同的微服务可以做负载均衡，提高性能和可靠性。正是因为相同微服务可以有多个不同实例，让服务按需动态伸缩成为可能，在高峰期可以启动更多的相同的微服务实例为更多用户服务，以此提高响应速度。同时这种机制也提供了高可靠性，在某个微服务故障后，其他相同的微服务可以接替其工作，对外表现为某个设备故障后业务不中断。同样的道理，微服务本身是不会去关心系统负载的，那么什么时候应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡的系统在起作用。
微服务可以独立部署和对外提供服务，微服务的业务上线和下线是动态的，当一个新的微服务上线时，用户是如何访问到这种新的服务？这就需要有一个统一的入口，新的服务可以动态的注册到这个入口上，用户每次访问时可以从这个入口拿到系统所有服务的访问地址。这个统一的系统入口并不是微服务本身的一部分，所以这种能力需要系统单独提供。
还有一些企业级关注的系统问题，比如，安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？等等这些问题都不是单个微服务考虑的范畴，而需要有一个系统性的考虑和设计，让每个微服务都能够按照系统性的要求和约束提供对应的安全性，可靠性，可维护性的能力。

微服务的设计原则

AKF分拆原则
详细参考：《scale cube(伸缩立方/扩展立方)学习 - 草稿》
前端后端分离
前后端分离的原则，简单的来讲就是前端和后端代码的分离，我们推荐的模式是最好采用物理分离的办法部署，进一步促使更加彻底的分离，如果继续直接使用服务器端模板技术，如jsp把java，js，html，css都堆到一个页面中，稍微有点复杂一点的页面就没有办法维护了。
好处：

前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端用户体验优化效果更好
分离模式下，前后端交互界面更清晰，就剩下接口模型，后端的接口简介明了，更容易维护
前端多渠道集成场景更容易实现，后端服务器无需变更，采用统一的数据和模型，可以支持多个前端，例如微信H5前端，PC前端，Android前端，IOS前端

无状态服务
一般说来，微服务架构的目的之一，是通过多进程承载高并发，根据并发的压力用多个副本共同承担流量。阻碍单体架构变为分布式架构的关键点就在于状态的处理——如果状态全部保存在本地，无论在内存还是硬盘，都会给架构的横向扩展带来瓶颈，因为这样新启动的进程根本无法处理那些保存在原来进程的用户的数据。所以要将整个架构分成无状态和有状态两个部分，业务逻辑的部分作为无状态的部分，很容易的横向扩展，在用户分发的时候，可以很容易分发到新的进程进行处理；状态保存在后端有状态的中间件中，如缓存、数据库、对象存储、大数据平台、消息队列等，这些中间件设计之初，就考虑了扩容时状态的迁移、复制、同步等机制，不用业务层关心。

参考：《微服务的无状态？》回答，https://www.zhihu.com/question/54437341?sort=created
4. RestFul风格
好处：

无状态协议HTTP，具备先天优势，扩展能力很强，例如需要安全加密，有现有的成熟解决方案HTTPS即可
JSON报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好
语言无关，各大热门语言都提供了成熟的RestFul API 框架，相对其他的一些RPC框架生态更加完整。

核心组件

服务注册与发现

主要解决硬编码问题。
详细参考：「Chris Richardson 微服务系列」服务发现的可行方案以及实践案例

配置中心

主要解决分布式集群系统的配置问题。
详细参考：微服务分布式集群之配置中心，为什么要配置中心？

服务限流、降级、熔断

主要解决流量控制问题。
详细参考：服务降级、熔断、限流的区别

服务网关

Service Gateway，系统的入口，封装了应用程序的内部结构，为客户端提供统一服务，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证、鉴权、监控、缓存、负载均衡、流量管控、路由转发等等
主要解决一下几个问题：

客户端多次请求不同的微服务，增加客户端的复杂性，
认证复杂，每个服务都要进行认证；
http请求增加，效率不高；
存在跨域请求，比较复杂。

有如下几个优点：

减少客户端与微服务之间的调用次数，提高效率；
便于监控，可在网关中监控数据，可以做统一切面任务处理；
便于认证，只需要在网关进行认证即可，无需每个微服务都进行认证；
降低客户端与服务端的耦合度。
参考：《微服务之服务网关》，https://www.jianshu.com/p/977b291e1247

分布式链路追踪

主要解决问题定位的问题。
详细参考：分布式链路追踪

负载均衡

实现微服务的高并发、高可用。
详细参考：微服务之负载均衡

统一认证与授权

解决多系统之间的统一身份管理、单点登录问题。
详细参考：微服务架构下的统一身份认证和授权

其他组件

自动化测试与质量管理

UI/UE测试
端对端测试
单元测试
API测试
A/B测试
冒烟和回归测试
静态代码分析
SonarQube质量监控

自动化部署

Nexus私有仓库搭建
Ansible自动化自动化运维
持续集成
- Jenkins持续集成工具
- Maven项目构建和管理工具
- SonarQube质量监控工具
灰度发布

日志收集与监控

ELK搜集与分析
ELK是三个开源软件的缩写，分别表示：Elasticsearch , Logstash, Kibana , 它们都是开源软件。新增了一个FileBeat，它是一个轻量级的日志收集处理工具(Agent)，Filebeat占用资源少，适合于在各个服务器上搜集日志后传输给Logstash，官方也推荐此工具。
Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
Logstash 主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。
Kibana 也是一个开源和免费的工具，Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助汇总、分析和搜索重要数据日志。
Filebeat隶属于Beats。目前Beats包含四种工具：
Packetbeat（搜集网络流量数据）
Topbeat（搜集系统、进程和文件系统级别的 CPU 和内存使用情况等数据）
Filebeat（搜集文件数据）
Winlogbeat（搜集 Windows 事件日志数据）
系统监控
- 进程监控
- 数据波动监控
- 常用监控命令：top、iostat、vmstat、…
运维监控
- Zabbix
APM监控
APM（ApplicationPerformance Management）是一种应用性能监控工具，通过汇聚业务系统各处理环节的实时数据，分析业务系统各事务处理的交易路径和处理时间，实现对应用的全链路性能监测。目前主流的APM工具，基本都是参考了Google的Dapper（大规模分布式系统的跟踪系统）体系，通过跟踪业务请求的处理过程，完成对应用系统在前后端处理、服务端调用的性能消耗跟踪，提供可视化的界面来展示对跟踪数据的分析。
APM工具与传统的性能监控工具的区别在于，不仅仅提供一些零散的资源监控点和指标，其主要关注在系统内部执行、系统间调用的性能瓶颈分析，这样更有利于定位到问题的具体原因。
- PinPoint
- SkyWalking