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