《微服务架构与实践》
一 单块架构
1 定义:对于这种功能集中、代码和数据中心化、一个发布包、部署后运行在同一进程的应用程序,我们通常称之为单块架构应用,并非物理上的分层。
2 单层架构:数据 逻辑 页面 混合
3 三层架构:
1)表示层:数据显示和用户交互
2)业务逻辑层:业务逻辑处理
3)数据访问层:数据存储访问
4 优势: 比较适合小项目
易于开发:开发简单直接,集中式管理,基本不会重复开发,集成工具适合
易于测试:单进程
易于部署:单项目包,功能都在本地,没有分布式的管理开销和调用开销
易于水平伸缩:发布相同的项目包,部署多个运行环境,使用负载均衡器分发,克隆
5 挑战:
开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断
代码维护难:代码功能耦合在一起,新人不知道何从下手
部署不灵活:构建时间长,任何小修改必须重新构建整个项目,这个过程往往很长
稳定性不高:一个微不足道的小问题,可以导致整个应用挂掉
维护成本增加:功能多,团队大,管理复杂,缺陷修复容易导致新的缺陷问题
持续交付周期长:
技术选型成本高:采用统一的技术平台或方案开发,当尝试引入新的框架、技术或对技术站升级会面临不小的风险。技术变化快,平滑完成替代较难。
可扩展性差:无法满足高并发情况下的业务需求
构建全功能团队难:单块架构往往以技能为单位进行分组,如前端、业务层、数据库团队等。
二 微服务架构
微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。
——摘自马丁· 福勒先生的博客
1 特点:
1)微
微服务架构通过对特定业务领域的分析与建模,将复杂的应用分解成小而专、低耦合并且高度自治的一组服务。微的定义最好符合项目的敏捷开发周期。
2)单一职责
业务逻辑单一,高内聚低耦合,不同服务通过管道等方式灵活组合。
注:面向对象设计之SOLID原则
3)轻量级通信
轻量级通信机制通常指语言无关、平台无关的交互方式。通信消息格式,如xml、json等,他们的解析和使用基本与语言、平台无关。通信协议,通常基于HTTP,能让服务间的通信标准化、无状态化。REST是实现服务之间互相协作的轻量级通信机制之一。
4)独立性
开发测试部署的独立。每个服务都是一个独立单元,有独立的代码库。服务与服务隔离。
5)进程隔离
每个服务都运行在不同的进程中,可以部署在不同节点。组件一般指独立升级 独立替换掉的部分。
2 背景技术
1)互联网时代的产品通常有两类特点:需求变化快和用户群体庞大。在这种情况下,如何从系统架构的角度出发,构建灵活、易扩展的系统,快速应对需求 的变化;同时,随着用户量的增加,如何保证系统的可伸缩性、高可用性,成为系统架构面临的挑战。
2)敏捷、精益方法论、DevOps的深入人心
精益创业(Lean Startup)帮助组织分析并建立最小可实行产品(Minimum Viable Product),通过迭代持续改进;敏捷方法帮助组织消除浪费,通过反 馈不断找到正确的方向;持续交付帮助组织构建更快、更可靠、可频繁发布的交付机制。DevOps文化的推行打破了传统开发与运维之间的壁垒,帮助组织形成 更高效的、开发与运维高度协作的交付团队。
3)虚拟化技术和容器化技术
虚拟化技术和基础设施自动化(Infrastructure As Code)的快速发展极大的简化了基础设施的创建、配置以及系统的安装和部署。譬如云平台的成熟以及像 Chef、Puppet、Ansible等工具的使用,让更多的基础设施能够通过自动化的方式动态创建。
容器花技术的发展以及Docker的出现,更是将虚拟化技术推向了一个史无前例的高潮。
3 SOA面向服务架构
SOA阐述了“对于复杂的企业IT系统,应按照不同的、可重用的粒度划分,将功能相关的一组功能提供者组织在一起为消费者提供服务”,其目的是为了解决企业内部不同IT资源之间无法互联而导致的信息孤岛问题。直到2000年左右,ESB(Enterprise Service Bus)、WebService、SOAP等这类技术的出现,才使得SOA渐渐落地。
实际上, SOA的概念和微服务思想几乎一致。主要区别如下表所示:
相比传统SOA的服务实现方式,微服务更具有灵活性、可实施性以及可扩展性,其强调的是一种独立测试、独立部署、独立运行的软件架构模式。
4 微服务本质
服务作为组件
传统实现组件方式是隔离独立的部分或抽出公用的部分,构建共享库,从而达到解耦和复用的效果。服务之间定义清晰、语言无关、平台无关的接口。
围绕业务组织团队
关注产品而非项目
技术多样性
业务数据独立
提供业务数据接口,而非公用数据库
基础设施自动化
每个服务需分别部署,则部署 运维的成本增加,对持续交付和部署流水线要求高。实现基础设施的自动化促进微服务构建。
演进式架构 敏捷开发 版本更新
5 微服务实施因素
分布式系统的复杂度
微服务架构师一种基于分布式的系统。
性能:多服务之间响应延迟及协作
可靠性:单点故障率增大
异步:
数据一致性:分布式事务管理 或保证数据的瞬时一致性
工具:IDE对微服务的支持不太好
运维成本
配置信息:
部署
监控与告警
日志收集
部署自动化
构建有效的自动化部署流水线
DevOps与组织架构
微服务不仅是一种架构模型,也表现出一种组织模型(开发者将承担部署运维监控)
服务间依赖测试
服务间依赖管理
三 微服务实践/项目开发流程
敏捷开发 自动化工具
1 API实现(REST)
选择合适的开发语言及开发框架
选择合适的代码仓库,svn、git
2 代码检查
1)代码自动化测试工具
2)单元测试覆盖率统计
3)代码静态检查,如代码的可读性、命名风格及统一的格式等
4)代码复杂度检查
可集成,如自动化测试的同时进行代码的静态检查
3 代码构建
代码构建工具及构建所生成文件类型,如war、jar、镜像等
4 项目部署
基础设施自动化(Puppet Ambari等)
自动化部署,如部署脚本deploy.sh,可包括基础设施环境准备
5 持续交付流水线
持续集成环境,如jenkins
持续交付:小批量价值流动 频繁可发布 快速反馈
1 提交阶段
代码编译 静态检查 单元测试等等
持续集成工具可通过WebHook的方式检测到代码仓库的提交并触发相应的处理机制,可以轮询的方式定期检测代码库(提交版本时间)的变化。
2 构建阶段
构建部署包,提交阶段完成后触发构建,注意部署包的版本定义
3 部署阶段
测试环境
生产环境
基础环境搭建,如tomcat等,执行部署脚本deploy.sh等
6 日志聚合
日志聚合工具 splunk kafka flume
数据采集 数据存储 高效索引 数据搜索 数据分析
7 监控与告警
主机监控 基础设施 Nagios zabbix
应用监控 项目相关的状态
告警 服务出现异常通知相关人员修复
8 功能迭代
服务描述文件:服务介绍 (名称 功能) 服务维护者 服务级信息 运行环境(地址) 开发(搭建 运行) 测试 构建 部署 运维(日志URL 监控URL)
四 微服务进阶
1 轻量级通信机制
定义:平台无关、语言无关的消息通信协议
同步通信:请求->等待->响应->处理
1)远程过程调用RPC:
典型的分布式节点间同步通信
语言依赖
传输格式为二进制 一端变化另一端也许对应修改
2)表述性状态传递REST
以资源为核心、以HTTP为操作方式 HTTP通信是同步的
核心:资源:信息实体的抽象
表述:对资源某一特定时刻的状态描述,如json格式等,URI仅代表资源的实体,HTTP请求头Accept、Content-Type字段才是表述
状态转移:客户端同服务器端交互的过程中,客户端能通过资源的表述来实现操作资源的目的。
统一接口:GET获取资源 POST新建资源 PUT更新资源 DELETE销毁资源