系列文章目录：
如何定义架构师
架构师从英文单词Architect翻译而来，在英文中，Architect原来的意思是“建筑师”。作者吐槽英文中架构师与传统的建筑师单词相同，但实际的工作性质并不相同，以致于在英文的语境中会造成理解上的差异。
传统的建筑师在设计建筑时要求极端地精确，在正式施工之前会进行完整的论证、设计、计划等，不允许出现任何差错；而软件架构师则地面对的问题更加不可测，软件在使用的过程中会面临大量的需求变更，甚至在发布至正式环境后仍然不断演化。
因此软件架构师必须要改变那种一开始就要设计出完美产品的想法，相反，我们应该设计出一个合理的框架，在这个框架中慢慢地演化出正确的系统。这就像城市规划师一样，他的职责是优化城镇布局，使其易于现有居民生活， 同时也会考虑一些未来的变化，如划分工业区和居民区，建在工业区的民居是不允许的，居民区的污水处理厂也是不允许的。城市就在这样的大原则下逐步演化。
未来的变化很难预见，所以与其对所有变化的可能性进行预测，不如做一个允许变化的计划，为此，应该：专注在大方法向，避免对所有事件做过于详尽的设计，只在有限的情况下参与到非常具体的细节实现中来，要保证系统不但能够满足当前的需求，还能应对将来的变化。因而，我们更愿意把架构师叫成演化式架构师。
演化式架构师的职责
1.关心服务之间的事务，多于关注服务内部发生的事情
这并不意味着服务内部的完全自治，这要视情况而定，如果整个团队采用了10种不同的技术栈，可能意味着团队的学习成本更高；或者每个服务暴露出来的接口标准都不一致，这将造成灾难。最低的要求是花时间跟每个服务团队在一起工作。
2.让系统设计原则服务于最大目标，让实践来巩固原则
假如公司的目标是：快速占领东南亚新市场，那么你的原则可能就是要求服务必须能方便地部署到相应的国家，在实践层面，我们可能会寻找能提供全球化的云厂商来实现我们的需求。
原则与实战有时难以区分，但只要把握：重要的原则用来指导系统的演化，同时也要有一些细节来指导如何实现这些原则，就可以了。
3.全局掌控微服务的状态
必须全局掌握微服务的健康状态，将这些状态信息进行统一管理。
要全局掌握微服务的安全性，不能让一个异常的服务毁了整个系统，因此每个服务必须很好地应对其他服务的错误请求。
4.代码治理
提供最佳实践范例和代码模板来保证质量，提供统一的服务来保证效率，在DRY中寻求平衡。
5.技术负债
有时为了服务于最大目标，在短时间内可能会忽略一些原则和最佳实践，虽然这短期能带来一些利益，但长期来年进要付出代价的。
不光走捷径会引入技术负债，有时系统的目标发生改变也会引用技术债务。
架构师应能提供一些温和的指导，然后让团队自行决定如何偿还这些技术负债。
6.团队领导
不要总是施加你的影响力，与各个服务团队一起工作，即使时间不那么多，从而了解所做的决定对团队造成的影响。可以从各服务团队抽一个人出来形成一个团队治理小组。
参考
《微服务设计》（Sam Newman 著 / 崔力强 张骏 译）