演进式架构师
系统的成功靠不断的取舍实现
1. 架构师的职责
1) 技术愿景、技术领导者，带领团队交付客户想要的系统
2) 从更高层次思考，权衡利弊，作出抉择
2. 架构师的演化视角
1) 软件是持续演化的，不是一成不变的。
2) 对于架构师来讲，不要想着一开始就设计出完美产品，而是要设计一个合理的框架，在这个框架下可以逐渐演化出客户想要的系统。
3) 系统不但要满足当前的需要，还能够应对将来的变化
3. 微服务架构师关注点
应该关注：
1) 分区：划分服务的边界，确定服务的粒度
2) 区域间的交互：不同的服务之间是如何交互，制定统一的接口，比如REST接口
3) 对整个系统的健康进行监控
4) 编码：架构师需要花时间和开发工程师在一起，理想状况下应该一起编码
不应该关注：
1) 过多关注每个区域内发生的事情：每个服务内部可以允许团队自己选择不同的技术栈或者数据存储技术
4. 微服务架构的目标、原则与实践
1) 业务部门的目标：
确保技术和业务层面能保持一致
2) 原则：
区分约束和原则：约束不能改变的，而原则是可以改变的。
Heroku的12 Factors
3) 原则和实践相结合
实践：a. 保证原则得到实施；b. 指导如何完成任务；c.是和技术相关的；d.比较底层的；e. 例如：代码规范、日志数据格式、http/rest作为标准集成风格，服务部署在不同的aws账户中等。
原则指导系统的演化
实践：指导如何实现原则的细节
不同的实践后可以有一个原则：.Net 团队／Java团队都各有自己的实践，但背后的原则是相同的。
目标 原则 实践
5. 微服务架构的要求
1) 监控
a. 原则：清晰描绘出跨服务系统的健康状态
b. 实践：每个服务主动把标准化的数据推送到一个集中的位置。例如：Graphite来收集指标数据；Nagios来检测健康状态；轮询系统来从各个节点收集数据等。
2) 接口
a. 原则：选用少数几种明确的接口
b. 实践：
i. 使用一种标准的接口
ii. 不仅仅是接口的技术和协议
iii. Url中使用动词还是名词
iv. 资源的分页
v. Api的版本管理
3) 架构安全性
a. 原则：保证每个服务都可以应对下游服务的错误请求
b. 实践：
i. 每个下游服务使用自己的连接池
ii. 每个服务使用一个断路器
iii. 返回码遵守一定的规则：正常且被正确处理的请求；错误请求；被访问的服务宕机，无法判断请求是否正常
4) 代码治理
a. 原则：使用简单的方式把事情做对
b. 实践：
i. 范例：代码范例
ii. 服务代码模板：实现一个新服务时，所用实现核心属性的那些代码都是现成的，即基于模板的。
6. 技术债务及例外管理
技术债务：
无法遵守原则会导致技术债务。
架构师要理解债务的层次，对系统的影响，做出权衡
例外管理：
系统偏离了制定的原则和实践式的处理方式。如果例外很多，要修改原则和实践以应对真正的需求。
比如：
在大多数场景下使用MySQL做存储，如果时数据快速增长的场景，可以使用Cassandra
7. 治理：
COBIT(Control Objectives for Information and Related Technology)对治理的定义：
治理通过评估干系人的需求、当前状况及下一步的可能性来确保企业目标的达成，通过排优先级和做决策来设定方向。对于已经达成一致的方向和目标进行监督。
治理确保构建的系统服务技术愿景，并在需要的时候对愿景进行演化。
治理是个小组活动，小组由技术专家领导，并要有一线人员参与。这个小组也负责跟踪和管理技术风险。
