梳理下概念

这本书比较泛泛而谈, 适合用来梳理下微服务的概念. 前面对微服务技术发展的总结不错, 后面实践部分的配置意义不大(细节可以 Google). 贴一下笔记.

## 单块架构
随着时代的发展, 软件系统中的逻辑通常被分为 3 层结构: 表示层, 业务逻辑层, 数据访问层. 分层是在逻辑上的, 最终构建成一个发布包, 运行在同一个进程中, 这就是单块架构.

单块架构易于部署(所有功能都会打成一个包), 易于水平伸缩(增加新的节点, 直接运行). 但仍面临挑战:

开发上的挑战:
1) 随着团队的增加, 团队中沟通协调的成本显著(非线性)增加.
2) 随着单块应用代码量的增加, 对代码做修改的成本显著(非线性)增加, 部署流水线时间增加. 容易陷入”修复越多, 缺陷越多”的恶性循环.
3) 新人培训周期变长: 系统越来越臃肿的必然结果
4) 技术栈难以升级, 代码量的增加导致依赖固化, 难以升级

性能上的挑战:
1) 容易水平扩展, 但扩展不能充分利用资源. 比如 cpu 和 内存, 如果整体应用偏向 cpu, 那么每个节点都会有闲置的内存资源; 反之, 每个节点都有闲置的 cpu 资源.

## 微服务架构
关键就是”拆”: 将单一应用拆分为一组服务, 服务间互相协调, 配合. 具体来说, 每个服务运行在独立的进程中, 能被独立地部署到生产环境; 服务间通过通信机制相互配合(RESTful API / 专有协议).

具体来说, 先要考虑以下几点:
**粒度**
微服务的粒度遵循业务逻辑上的单一职责和团队上的独立.

**轻量级通信**
语言无关, 平台无关

**独立性**
开发团队, 测试, 构建, 部署的独立, 数据库独立

难点在数据一致性/异步, 同时在性能和运维监控(配置, 部署, 监控报警, 日志收集)方面面临挑战. 因为微服务粒度更小, 功能和边界清晰, 功能方面的问题更少, 而服务构建方面比传统的单块应用复杂(DevOps).

## 实践
基于 GitHub, Docker Hub, Snap-CI 来构建持续交付流水线. 主要是工具的配置, 几页几页的配置项, 水分多.

**日志聚合**
用的 Splunk. 又是讲的如何配置

**监控报警**
用的 Nagios.

## 持续交付
RUP -> 敏捷 -> XP -> Scrum -> 精益创业 -> DevOps 过程中一直降低交付成本, 提高效率. 我的理解是, 尽量压缩开发与产品间的空间, 提升开发 -> 部署 -> 使用过程的一致性(连续性). 微服务化导致应用更多, 联系更复杂, 粒度更小, 发布更频繁; 因此需要把以前的编译/打包/发布改成了更精细的流水线.

**持续集成**
Jenkins

**轻量级通信**
1. 当前的 RPC: Thrift / protocol buffers. 面向对象的 RPC.
2. RESTful 风格: 基于 HTTP, 因此有性能问题(对比二进制协议)
3. 消息队列. 典型的场景是: 注册后系统发送邮件. 触发消费事件的两种模式: 1) 消费者定时 pull 2) 发布者发布时 push