《《架构师》2016年1月》读后感1100字
微服务架构与实践
技术上讲，持续交付是软件系统的构建、部署、测试、审核、发布过程的一种自动化实现，而其中的核心则是部署流水线。
1 持续交付的核心
持续交付的核心是 小 频 快。
1.小批量的价值流动
通过自动化部署，将业务功能以小批量的方式，从需求端实现到用户端。
2.高频地发布
通过构建部署自动化，高频率地将小批量的业务需求实现、发布。
3.快速反馈
通过搭建有效的反馈机制，快速验证需求。通过反馈，及时指导业务团队调整需求。
总的来说，持续交付就是让业务功能在整个软件交付过程中，以小批量的方式，频繁地低风险地将业务功能发布，并建立有效的反馈机制，及时指导团队调整需求。
2 微服务架构与持续交付
在微服务架构中，每个服务都是独立的可部署的业务单元，对应的都有自己一套部署流水线。
在微服务中构建一套可持续交付的流水线，各个阶段都有注意点。
2.1开发阶段
* 通过git等建立独立的代码库
* 代码静态检查工具
* 易于本地运行，可考虑模拟外部资源
* 清晰的服务说明README.md
服务说明可以包含以下模块
– 服务说明
– 服务的维护者
– 服务的可用期
– 服务运行的环境
– 开发相关
– 测试相关
– 继承构建
– 部署
– 运维相关信息
* 服务说明包括服务提供什么功能，谁是服务的调用者。
* 服务的维护者包括维护者的名称邮件等等。
* 服务的可用期包括可用时间(7*24)、可用率(可用率是指服务可以正常访问的时间占总时间的百分比，如99.9%)、响应时间。
* 服务的运行环境分三块：开发、测试、正式环境信息。
* 开发相关信息则包括如何搭建开发环境、如何运行、如何定位问题。
* 测试信息有测试策略、如何测试、如何查看测试结果(覆盖率、运行时间、性能等)
* 部署：如何部署到不同环境、如何验证部署后的功能
* 运维：日志告警监控的访问方式
2.2 测试
对于服务，通常不涉及用户体验层，更关注数据层。
单元测试保障内部逻辑，接口测试保障接口。
2.3 持续集成
当成员提交代码后，配置好的持续集成服务会检测到代码变化，进行一些列的静态检查、测试、构建等。
2.4 构建部署
选择部署环境并制定部署方案。
亚马逊的AWS云环境，可以方便地使用其提供的系统映像（AMI）来完成部署。
2.5 运维
为服务提供监控告警、快速分析定位问题都可归纳成运维。
– 监控。监控分为系统监控和业务监控。系统监控关注服务所运行服务器的cpu、磁盘、网络情况等。业务监控则包括业务所依赖的服务情况、业务本身情况。
– 告警。当监控发现问题时，需要及时告警对应人员。
– 日志聚合。微服务多了之后，需要将不同节点上的日志聚合一起，以便分析。
本文首先讲述了持续交付的概念及其核心，接着讨论了在微服务架构的实施过程中，如果建立基于服务的细粒度的持续交付流水线，应该考虑的因素。