微服务架构与实践学习笔记

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/bobshute/article/details/69822631

摘要

微服务,持续集成(Jenkins,Snap-CI),构建(Maven,Gradle),部署(Docker),持续交付(Jenkins),日志聚合(ELK,Splunk),运维(监控警告Zabbix,Nagios)
本内容为学习<<微服务架构与实践>>(王磊 著) 的读书笔记,为自我学习整理使用,如果喜欢书本内容,请到如下地址购买: https://item.jd.com/11826753.html

1. 单块架构及其面临的挑战

1.1 三层架构

三层架构包括表示层、业务逻辑层、数据访问层。

1.2 单块架构

所有的功能在一个工程项目中。
单块架构常见的架

优点 缺点 说明
易于开发 维护成本增加 庞大复杂
易于测试 持续交互周期长 构建部署时间长,开发团队耦合度高各功能合并难
易于部署 新人培养周期长 代码复杂难学习
易于水平伸缩 技术选型成本高 尾大难掉
可扩展性差 垂直扩展(机器),水平扩展(难集群)
构建全功能团队难 页面/后端工程师协作难

1.3 互联网产品特性

创新成本低、需求变化快、用户群里庞大。单块架构无法满足。

2.微服务架构综述

2.1 什么是微服务

微服务架构模型(Microservice Architect Pattern)

引用下当今世界软件开发领域最具影响力的五位大师之一的定义:

    微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间 互相协调、互相配合 ,为用户提供最终价值。每个服务运行在其独立的进程中,服务于服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。 
    —摘自 马丁·福勒先生的博客

2.1.1 多微才够微

  微服务架构通过对特定业务领域的分析与建模,将复杂的应用分解成为小而专一、耦合度低并且高度自治的一组服务。
  代码行数和开发时间都不能衡量是否”微”的重要因素.
  “微”所表达的是一种设计思想和指导方针,是团队或组织共同努力找到的一个平衡点.仁者见仁智者见智,但要遵循如下2点:
业务独立性: 保证微服务具有业务独立性的单元,如:
  业务: 订单,产品,合同
  功能:发送邮件,单点登录验证,数据库同步
     
  团队自主性: 考虑团队的沟通及写作成本,一般建议不超过十人.

2.1.2 单一职责

高内聚:一个模块各个元素彼此结合的紧密度高.
低耦合:对于一个完整的系统,模块与模块之间,尽可能的独立存在.
SRP :(Single Responsibility Principle,单一职责原则):即一个对象应该只有一个发生变化的原因,如果一个对象可被多个原因改变,那么说明这个对象承担了多个职责.
### 2.1.2 轻量级通信
服务之间应通过轻量级的通信机制,实现彼此间的互通互联,互相协作.
格式: XML,JSON
协议: HTTP,REST(Representational State Transfer,表述性状态传递)

2.1.3 独立性

交付过程中,开发,测试以及部署的独立性。改变某个服务时,对其它服务不产生影响。

2.1.4 进程隔离

理论上,多个服务部署到一个节点上,并且能运行在不同的进程中,且互不影响,但是不推荐这么做。
因为增加了部署和扩展的复杂度,建议还是一个服务一个节点。

总结: 微服务架构就是将单一的应用程序划分为一组小的服务,每个服务都是具有业务属性的独立单元,同时能够被独立开发,独立运行,独立测试以及独立部署.

2.2 微服务的诞生背景

互联网行业的快速发展,敏捷、精益方法论的深入人心,单块架构系统面临的挑战,容器虚拟化技术(Docker),

2.3 微服务和SOA

2.3.1 SOA(Service-Oriented Architecture,面向服务架构)

2.3.2 微服务和SOA

SOA 微服务架构实现
企业级,自顶向下开展实施 团队级,自底向上开展实施
服务由多个子系统组成,粒度大 一个系统被拆分成多个服务,粒度细
企业服务总线,集中式的服务架构 无集中式总线,松散的服务架构
集成方式复杂( ESB,WebService,SOAP) 集成方式简单(HTTP,REST,JSON)
单块架构系统,相互依赖,部署复杂 服务能独立部署

SOA和微服务架构的区别? https://www.zhihu.com/question/37808426

2.4 微服务的本质

1) 服务作为组件(组件能独立部署);2)围绕业务组织团队;3)关注产品而非项目;4)技术多样性(支持各种开发语言);5)业务数据独立(数据库也独立);6)基础设置自动化;7)演进式架构

2.5 微服务不是银弹

独立性,单一职责,技术多样性
2.5.1 分布式系统的复杂度:性能,可靠性,异步,数据一致性,工具
2.5.2 运维成本 配置,部署,监控与告警,日志收集
2.5.3 部署自动化
2.5.4 DevOps 与组织架构
2.5.5 服务间的依赖测试
2.5.6 服务间的依赖管理
微服务架构将一个应用拆分成多个独立的、具有业务属性的服务,每个服务运行在不同的进程中,服务与服务之间通过轻量级的通信机制互相协作、互相配合,从而为终端用户提供业务价值。同时,每个服务可以根据业务逻辑,采用不同的语言、框架、工具以及存储技术来解决业务问题。因此,微服务架构强调的是一种独立开发、独立测试、独立部署、独立运行的高度自治的架构模式,也是一种更灵活、更开放、更松散的演进式架构。

3.构建第一个服务

3.1 场景分析;3.2任务拆分
1)Hello World API;2)代码测试与静态检查;3)构建Docker映像;4)部署Docker映像;5)持续集成与交付;6)监控与告警;7)日志聚合;8)功能迭代

4.Hello World API

Ruby;
Rack:Ruby的Web应用抽象接口;
Rack Gem: Rack辅助类的集合;
RSpec:代码测试工具
Rubocop:代码的静态检查

5.构建Docker映像

Docker:开源的Linux 应用容器(Linux Container)引擎。
Boot2docker:Mac下轻松搭建整个Docker
Docker Hub:
Docker 映像存储介质的比较

私有Docker Registy 云存储 Docker Hub
发布操作 使用Docker Push 使用Docker save
映像类型 Docker映像 保存成文件系统的tar包
获取操作 使用Docker pull 使用 Docker Load
权限控制 访问权限控制不灵活 访问权限控制灵活
备份成本 备份成本高 云存储平台提供备份机制,备份成本低

6.部署Docker映像

AWS:Amazon Web Services
Amazon EC2: (Amazon Elastic Compute Cloud)
Infrastructure As Code:基础设施自动化

7.持续交付流水线

Snap-CI: 持续集成工具,ThoughtWorks
提交、验证、构建、发布。
Jenkins

8.日志聚合

Splunk:日志管理工具,日志聚合,日志搜索,语义提取,对结果进行分组、联合、拆分和格式化,强大的可视化功能,电子邮件提醒功能。
核心:数据(采集器)转发器、数据索引器、搜索、分析和可视化、
LogStash:收集日志、过滤日志、结果输出。
ELK: ElasticSearch、LogStash、Kibana

9.监控与告警

Zabbix、Ganglia、NewRelic、Nagios、OneAPM。
Nagios: Nagios Ain’t Goona Insist on Saintood,免费的开源IT基础设施监控系统. 能有效监控Windows、LInux、VMware和UNIX主机状态以及交换机、路由器等网络设置。同事,它能够实现错误通知、事件处理。一旦主机或服务状态出现异常,Nagios会发送邮件或短信第一时间通知IT运维人员,并在状态恢复正常后发出邮件或短信通知。
Nagios结构: Nagios核心、Nagios插件。
Nagios网站: http://www.nagios.org/
Nagios原理,Nagios安装,Nagios配置.

10.功能迭代

10.1定义模型;10.2持久化模型;10.3 定义表现形式,10.4实现API;10.5服务描述文件

11.微服务与持续交付

持续交付的核心:小、频、快。小批量价值流动,频繁可发布,快速反馈。
微服务架构与持续交付:
1) 开发
独立代码库、服务说明文件、代码所有权团队、有效的代码版本管理工具【git,Mercurial,svn】、代码静态检查工具【SonarQube,cane】、易于本地运行);
2) 测试:
集成测试的二义性,mock和stub,接口测试,测试的有效性
3) 持续集成: Jenkins,Bamboo,在线持续集成平台:Travis-CI,Snap-CI.
4) 构建: Docker
5) 部署: A.部署环境:基于云平台(IAAS,PAAS),基于数据中心,基于容器技术(Docker)
B.部署方式:手动部署,脚本部署,基础设施部署自动化(Chef,Puppet,Ansible),应用部署自动化,映像部署,容器部署
6)运维: 监控,告警,日志聚合
Asgard: netflix asgard https://github.com/Netflix/asgard

12. 微服务与轻量级通信机制

12.1 同步通信与异步通信

1)同步通信与一步通信的选择 ;
2)远程调用RPC(Remote Procedure Call 远程过程调用) 远程过程的核心:客服端/服务端模式(客户端客户代理存根[Stub],服务器代理存根[Skeleton]);RMI(Remote Method Invocation 远程方法调用)
优点:耦合度高
缺点:灵活性差,依赖于变成语言以及特定平台,
二进制,客户/服务端提供序列化,反序列化操作,任何一方发生变化,另一方就要造成影响
3)REST(Representational State Transfer 表述性状态描述;Resource 资源[返回数据],Representation 表达,State Transfer状态转移,Uniform Interface 统一接口 GET,POST,PUT,DELETE) 概述,软件架构风格,
优点 :与语言无关,与平台无关,水平伸缩容易.
缺点如何标准化资源结构:业务增长,逻辑增加后,服务器端对内容的响应结构会越来越复杂[响应结构:是指服务器段的响应内容结构,即资源结构],++可能企业内部的不同部门,不同小组,对同一资源,所定义的结构不尽相同++.
如何处理资源的相关链接: 大多数返回JSON,JSON最大的遗憾就是没有对超链接处理做内置的支持.对于调用的客户端,++每次需要查看相关的接口文档,才能了解如何修改资源的状态++.
如:多个接口:获取用户接口,获取用户好友接口,用户文章接口。如果REST只有开放三个接口,但是用户好友和用户文章实际上是用户接口的子链接就可以的,但是JSON不支持。
REST的HTTP并不是低延时通信的最好选择 对低延时要求的场景,可以选择底层协议,如果UDP(User Datagram Protocol)或其它的RPC框架。
开发成本略高 传输格式为JSON或XML,则需要来解析文本格式协议,还好当前开源工具库成熟。
4)HAL(Hypertext Application Language) : 轻量级超文本应用描述协议。HAL的实现基于REST,并有效的解决了REST中的资源结构标准化和如何有效定义资源链接的问题。
核心:状态(State),链接(Links),子资源(Embedded Resource)。
状态 资源本身固有的属性。
链接 定义了与当前资源相关的一组资源的链接的集合。包括链接名称、目标URI,访问URI的参数。
子资源 描述在当前资源的内容,其嵌套资源的定义。
HAL浏览器: (HAL Brower)
5)MQ :核心部分,访问方式.RabbitMQ,ActiveMQ,ZeroMQ
核心部分 : 持久性(内存,磁盘,数据库),排队标准(常见FIFO),安全策略,清理策略,处理通知
访问方式 拉模式,推模式
消息队列的优缺点优点: 服务间耦合,异步通信,消息的持久化以及恢复支持。
缺点: 实现复杂度的增加,平台或者协议依赖,维护成本高,

6)* 后台任务处理系统* Resque=>Sidekiq(ruby),Delayed_job
轻量级通信,维护成本低,SDK和API支持

远程方法调用 REST HAL 消息队列 后台任务系统
通信方式 同步通信 同步或异步通信 同步或异步通信 异步通信
平台依赖性 平台无关 平台无关
语言支持 语言无关 语言无关
学习成本
维护成本

13.微服务与测试

13.1微服务的结构

业务模型(Domain),业务逻辑(Service/Business Logic),模型存储(Respository),资源定义(Resource 包括表述内容,表述格式),网关集成(Gateway/Http Client).

13.2微服务的测试策略

测试金字塔. 单元测试,接口(契约)测试,集成测试,组件测试,端到端测试,探索.
单元测试 (Unit Testing)被测单元依赖于模拟部分(MOCK,STUB),被测单元依赖于真实部分.
接口(契约)测试 Pact测试框架
集成测试 (Integration Testing),自顶向下集成(Top-Down Integration),自底向上集成(Bottom-Up Integration).测试内容: 网关,模型存储.
集成测试弊端: 运行效率低,运行结果不稳定,反馈周期慢.
组件测试 (Component Testing),进程内测试,进程外测试.
端到端测试 (End-To-End Testing,System Testing)

14.使用微服务架构改造遗留系统

14.1 改造策略

最小修改(优先修改紧急,核心功能),功能剥离(构建接口,分离核心功能),数据解耦(数据库独立),数据同步(ETL Extract,Transform,Load),迭代替换(最小修改->功能剥离->数据解耦->数据同步(->独立服务)->功能剥离).

14.2快速开发实践

微服务快速开发模板(Microservice Template):快速开发模板(Webmachine或Grape 作为Web框架,RESTful和JSON构建服务之间的通信方式,RSpec作为测试框架),代码生成工具,持续集成模板(Bamboo),一键部署工具(Asgard)。

展开阅读全文

没有更多推荐了,返回首页