架构师应该设计一个合理的架构，后期可以慢慢的演化出正确的系统，不应该抱着一开始就能设计出完美的产品的想法。
设计出的架构不但能够保证系统能够满足当前的系统要求，还应该可以应对将来的变化。
服务边界：区分出各个服务的边界，各个服务中需要关注的重点，以及各个服务之间如何进行交互。
每个服务内部可以使用不同的技术栈或者数据储存技术。尽可能保证服务之间的交互使用相同的接口方式，保证服务间调用可以比较方便。例如如果服务一使用了restful、服务二使用了protocol buffers、服务三使用Java rmi，这样三个服务之间调用会比较复杂，不利于开发。
原则：做系统设计时需要需要各个方面的取舍：
为了和定制的的目标保持一样，我们会指定一些规则，这些规则称为原则。原则不是一成不变的，原则一般不应该超过10个，可以让开发人员方便记住。
推荐使用https://www.12factor.net/可以创建应用的设计原则。
原则可以自己决定，同时要显示的指出哪些是原则，哪些是约束。
实践：通过相应的实践保证原则能够得到实施，这些实践能够直到我们如何完成任务。
实践包含代码规范、日志数据收集或者http/rest作为标准继承风格等。
由于实践比较偏技术层面，因此其改变的频率会高于原则。
原则与实践结合
重要的原则可以指导系统的演化，同时也要有一些细节来指导如何实现这些原则。
要求的标准
决定原则和实践的时候，需要注意的一个重要因素是系统允许多少变化。
需要识别出各个服务之间应该遵守的通用规则，可以通过“给出一个服务的例子来阐述服务的特点”。
在优化单个服务的时候也要兼顾全局各个服务，可以通过“定义出一个好服务的属性”的方式来帮助我们实现平衡的方法。
监控
能够清晰的描绘出跨服务系统的健康状态非常重要。这必须在系统级别而非单个服务级别进行考虑。
可以选择使用“推送机制”，就是每个服务主动把数据推送到某个集中的位置。
也可以选择使用Nagios来检测健康状态，或者使用轮训系统来从各个节点收集数据。
每个服务的具体实现不同，因此不用为每个服务具体实现而改变监控系统。
日志功能和监控情况类似，也应该需要进行集中式管理。
接口
选择少数几种明确的接口技术有助于新消费者的集成。
可以使用一种、两种等，但是不用使用过多的技术集成方案。
通常来说使用Http/rest方式时可以优先考虑的。、
架构安全性
一个运行异常的服务可能导致整个系统的奔溃，因此要保证每个服务都可以应对下游服务的错误请求。
没有处理好下游服务请求的服务越多，我们系统就会越脆弱。
返回一致的错误信息，或者返回码应该遵守一定的规则。
对一下几种请求做出正确的处理可以帮助系统及时失败:
1、正常并且被正确处理的请求；
2、错误请求，并且服务识别出了它的错误；
3、被访问的服务宕机了，所以无法判断请求是否正常；
代码治理
提供规范和服务代码模板，可以帮助我们很快的达成共识。
规范
编写文档非常有用，如果一个项目中有一个比较好的代码规范可以用于被模仿，可以保证具体开发时用于模仿，并且即使出错也不会太离谱。
规范的代码模板中可以体现出设计的原则。
剪裁服务代码模板
当需要开发一个新的服务时，所有实现核心属性的那些代码应该是现成的。
针对自己的开发实践剪裁出一个服务代码模板，不但可以提供开发速度，同时还可以保证服务的质量。
如果不同服务的技术栈不同，那么也应该为不同的技术栈都提供一个服务代码模板。
创建服务代码模板时，需要通过合作的方式定义出具体的实践。
要注意一个问题：代码的重用，代码的重用可能导致服务间的耦合，如果核心服务代码模板进行升级，可能导致所有的服务都必须升级。
技术债务
有时候可能由于一些紧急的需求特性，而导致无法遵守技术定义的设计原则。这样做短期会有收益，但是从长期考虑可能会付出大的代价。
不光走捷径会导致技术债务的发生，有时候系统实现目标的变更，并且与现有的系统不符，这也会导致技术债务的出现。
架构师的职责就是从高层次出发，考虑如何权衡。理解技术债务的层次以及对系统的影响非常重要。