第二章：演化架构师

Posted 2021-01-15 use-d

架构师应该设计一个合理的架构，后期可以慢慢的演化出正确的系统，不应该抱着一开始就能设计出完美的产品的想法。

设计出的架构不但能够保证系统能够满足当前的系统要求，还应该可以应对将来的变化。

服务边界：区分出各个服务的边界，各个服务中需要关注的重点，以及各个服务之间如何进行交互。

每个服务内部可以使用不同的技术栈或者数据储存技术。尽可能保证服务之间的交互使用相同的接口方式，保证服务间调用可以比较方便。例如如果服务一使用了restful、服务二使用了protocol buffers、服务三使用Java rmi，这样三个服务之间调用会比较复杂，不利于开发。

原则：做系统设计时需要需要各个方面的取舍：

为了和定制的的目标保持一样，我们会指定一些规则，这些规则称为原则。原则不是一成不变的，原则一般不应该超过10个，可以让开发人员方便记住。

推荐使用https://www.12factor.net/可以创建应用的设计原则。

原则可以自己决定，同时要显示的指出哪些是原则，哪些是约束。

实践：通过相应的实践保证原则能够得到实施，这些实践能够直到我们如何完成任务。

实践包含代码规范、日志数据收集或者http/rest作为标准继承风格等。

由于实践比较偏技术层面，因此其改变的频率会高于原则。

原则与实践结合

重要的原则可以指导系统的演化，同时也要有一些细节来指导如何实现这些原则。

要求的标准

决定原则和实践的时候，需要注意的一个重要因素是系统允许多少变化。

需要识别出各个服务之间应该遵守的通用规则，可以通过“给出一个服务的例子来阐述服务的特点”。

在优化单个服务的时候也要兼顾全局各个服务，可以通过“定义出一个好服务的属性”的方式来帮助我们实现平衡的方法。

监控

能够清晰的描绘出跨服务系统的健康状态非常重要。这必须在系统级别而非单个服务级别进行考虑。

可以选择使用“推送机制”，就是每个服务主动把数据推送到某个集中的位置。

也可以选择使用Nagios来检测健康状态，或者使用轮训系统来从各个节点收集数据。

每个服务的具体实现不同，因此不用为每个服务具体实现而改变监控系统。

日志功能和监控情况类似，也应该需要进行集中式管理。

接口

选择少数几种明确的接口技术有助于新消费者的集成。

可以使用一种、两种等，但是不用使用过多的技术集成方案。

通常来说使用Http/rest方式时可以优先考虑的。、

架构安全性

一个运行异常的服务可能导致整个系统的奔溃，因此要保证每个服务都可以应对下游服务的错误请求。

没有处理好下游服务请求的服务越多，我们系统就会越脆弱。

返回一致的错误信息，或者返回码应该遵守一定的规则。

对一下几种请求做出正确的处理可以帮助系统及时失败:

1、正常并且被正确处理的请求；

2、错误请求，并且服务识别出了它的错误；

3、被访问的服务宕机了，所以无法判断请求是否正常；

代码治理

提供规范和服务代码模板，可以帮助我们很快的达成共识。

规范

编写文档非常有用，如果一个项目中有一个比较好的代码规范可以用于被模仿，可以保证具体开发时用于模仿，并且即使出错也不会太离谱。

规范的代码模板中可以体现出设计的原则。

剪裁服务代码模板

当需要开发一个新的服务时，所有实现核心属性的那些代码应该是现成的。

针对自己的开发实践剪裁出一个服务代码模板，不但可以提供开发速度，同时还可以保证服务的质量。

如果不同服务的技术栈不同，那么也应该为不同的技术栈都提供一个服务代码模板。

创建服务代码模板时，需要通过合作的方式定义出具体的实践。

要注意一个问题：代码的重用，代码的重用可能导致服务间的耦合，如果核心服务代码模板进行升级，可能导致所有的服务都必须升级。

技术债务

有时候可能由于一些紧急的需求特性，而导致无法遵守技术定义的设计原则。这样做短期会有收益，但是从长期考虑可能会付出大的代价。

不光走捷径会导致技术债务的发生，有时候系统实现目标的变更，并且与现有的系统不符，这也会导致技术债务的出现。

架构师的职责就是从高层次出发，考虑如何权衡。理解技术债务的层次以及对系统的影响非常重要。