- 一、单块架构及面临的挑战
单块的挑战
维护成本增加
持续交付周期长
新人培养周期长
技术选型成本高
可扩展性差
- 二、微服务架构综述
2.1 什么是微服务架构
1 观点：
- 绝大多数微服务的成功案例，都是从整体架构（Monolith）开始的。并且由于整体架构过于庞大，导致架构无法继续支撑。
- 绝大多数我所听说的系统，如果从一开始就使用微服务架构，最终都遇到了很严重的问题。
建议：
并不应该从项目一开始就使用微服务架构，即便你能够保证你的应用足够大，以至于使用微服务架构是值得的。
直接上微服务，鲜有成功之例子。
2 微服务的描述
微服务架构是一种架构模式，提倡将单一应用程序划分成一组小的服务，服务之间互相协调、配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务见采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。
3 多微才好？
原则：业务独立性；团队自主性（10人一下团队）
单一职责。
| SRP | The Single Responsibility Principle | 单一责任原则 |
| OCP | The Open Closed Principle | 开放封闭原则 |
| LSP | The Liskov Substitution Principle | 里氏替换原则 |
| DIP | The Dependency Inversion Principle | 依赖倒置原则 |
| ISP | The Interface Segregation Principle | 接口分离原则 |
4 轻量级的通信机制
5 独立性
6 进程隔离
2.2 诞生背景
1 互联网行业的快速发展
2 敏捷、精益、持续交付等方法论深入人心
3 单块架构的挑战
4 容器虚拟化技术的成熟 Docker
2.4 微服务本质
服务作为组件。服务之间定义清晰、语言无关、平台无关的接口。
围绕业务组织团队。
关注产品而非项目。
技术多样性。
业务数据独立。
基础设施自动化。DevOps
演进式架构
2.5 不是银弹！
这里列出缺点：
分布式系统的复杂度。性能、可靠性、异步、数据一致性、工具
运维成本。配置、部署、监控与告警、日志收集
部署自动化。必须自动化
DevOps与组织架构
依赖测试
依赖管理
- 三、实践篇
3.1 任务拆分
构建第一个hello world API
代码测试与静态检查
Docker映像构建
Docker映像部署
持续集成与交付
监控与告警
日志聚合
3.2 构建服务
提前将开发、测试、部署、运维、监控的流水线打通。
本书选择了ruby作为开发语言。
单元测试框架。JUnit。不是所有的单元都要测试
测试API。
代码静态检查。ide的check，或者firebug
3.3 Docker
已经是一项成熟且值得应用的技术。推荐。
构建映像。构建、运行容器、发布映像。注意自动化。
部署映像。基础设施自动化：分析配置文件、创建基础设施、get Docker映像、运行
3.4 持续交付流水线
本书代码托管在github上，采用了snap-CI作为持续交付工具。
实际需要考虑代码的托管方式，和局域网本的持续交付工具。
备选：thoughworks GO、Jenkins
任务：
1 提交。代码编译、静态检查、单元测试
2 验证。集成测试、用户行为测试、组件测试、性能测试。
3 构建。
4 发布。 测试环境、 类生产环境、 生产环境
触发 自动 手动 手动
数据来源 模拟 真实 真实
目的 验证功能 演示 真实的服务啊
3.5 日志聚合
Splunk
LogStash
初始的日志方式。
日志种类：标准、文件、syslog等
3.6 监控与告警
3.6 监控与告警
nagios系统监控。 it基础设施监控系统。
3.7 功能迭代
3.7 功能迭代
1 服务描述文件
服务描述
维护者
可用期
运行环境。生产、测试
开发。如何搭建、运行、调试
测试
构建。持续集成、描述、发布
部署
运维。日志、监控地址
四、进阶篇
4.1 持续交付
1 开发：独立的代码库；服务说明文件；代码所有权归团队；有效的版本管理；静态检查工具；易于本地运行
2 测试。mock和stub；接口测试。有效性
3 持续集成。
4 构建
5 部署。手动、脚本、基础设施自动化（chef、puppet、ansible）、应用部署自动化（映像部署、容器部署）
4.2 轻量级通信
1 同步和异步
2 RPC
3 REST
资源、表述、状态转移、统一接口
4 HAL。
5 消息队列ActiveMQ、rabbitMQ
6后台任务处理系统
4.3 测试