《微服务架构与实践》读书笔记一

《微服务架构与实践》
一 单块架构
　　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销毁资源