本章阐述了什么是架构师，列举了架构师应该承担的职责，有哪些原则方法可以指导工作。
1.什么是架构师
1.1 不准确的比较
计算机行业还很年轻，为了帮助别人理解我们到底是做什么的，我们需要来描述我们的职业。我们尝试借鉴其它行业。我们把自己称作软件“工程师”或者“建筑师”，而它们在社会中的重要性也很容易理解。
这个类比会造成一些问题。“建筑”倒塌的次数要比程序崩溃的次数少得多，所以与工程师相比是不公平的。建筑设计要严格的多，并且一旦确认，后续很少再会改动。而软件的改动则频繁的多，因为软件是需要根据不断变化的用户需求进行演化的。
架构师这个词已经被大众所接受了，所以现在我们能够做的事情就是在上下文中去重新定义这个词的含义。
1.2 架构师的演化视角
与建造建筑物相比，在软件中我们会面临大量的需求变更，使用的工具和技术也多种多样。我们创造的东西并不是在某个时间点之后就不再变化了，甚至发布到生产环境之后，软件还能继续演化。因此架构师必须改变那种从一开始就要设计出完美产品的想法，相反我们应设计出一个合理的框架，在这个框架下可以慢慢演化成正确的系统。
有一个角色可以更好的与IT架构师做类比，就是城市规划师。城市规划师的职责是优化城镇布局，使其更易于现有居民生活，同时也会考虑一些未来的因素。
架构师更应像城市规划那样专注于大方向，只在很有限的情况下参与到非常细节实现中来。他们需要保证系统不但能够满足当前的需求，还能够应对将来的变化。而且他们还应该保证在这个系统上工作的开发人员要和使用这个系统的用户一样开心。
2. 定义原则
为了和更大的目标保持一致，我们会制定一些具体的规则，并称之为原则，它不是一成不变的。举个例子，如果组织的一个战略目标是缩短新功能上线的周期，那么一个可能的原则就是，交付团队应该对整个软件生命周期有完全的控制权，这样他们就可以及时交付任何就绪的功能，而不受其它团队的限制。
我们通过相应的实践来保证原则能够得到实施，这些实践能够指导我们如何完成任务。通常这些实践是技术相关的，而且是比较底层的，所以任何一个开发人员都能够理解。这些实践包括代码规范，日志数据集中捕获或者HTTP/REST作为标准集成风格。由于实践比较偏技术层面，所以改变的频率会高于原则。
3. 要求的标准
各个微服务需要遵守一些通用性的规则，比如下面这些：
a.监控：能够清晰地描绘出跨服务系统的健康状态非常关键，这必须在系统级别而非单个服务级别进行考虑。
b.接口：选用少数几种明确的接口技术有助于新消费者的集成
c.架构安全性：一个运行异常的服务可能会毁了这个系统，而这种后果是我们无法承担的，所以我们必须保证每个服务都可以应对下游服务的错误请求。
4.代码治理
聚在一起，就如何做事情达成共识是一个好主意。但是，花时间保证人们按照这个共识来做事情就没那么有趣了，因为在各个服务中使用这些标准做法会成为开发人员的负担。比较奏效的两种方式是，提供范例和服务代码模板。
a.范例：如果你有一些很好的实践希望别人采纳，那么给出一系列的代码范例会很有帮助。这样做的一个初衷是：如果在系统中人们有比较好的代码范例可以模仿，那么他们就不会错的离谱。
b.裁剪服务代码模板：当开发人员要实现一个新服务时，所有实现核心属性的那些代码应该是现成的。针对自己的开发实践裁剪出一个服务代码模板，不但可以提供开发速度，还可以保证服务的质量。
5. 技术债务
有时候无法完全遵守技术愿景，比如为了发布一些紧急的特性，你可能会忽略一些约束。我们的技术愿景有其本身的道理，所以偏离了这个愿景短期可能会带来收益，但是长期来看还是要付出代价的。
架构师的职责就是从更高的层次出发，理解如何做权衡。理解债务的层次及其对系统的影响非常重要。
总结
下面是作者认为的一个演进式架构师应该承担的职责:
- 愿景：确保系统级有一个经过充分沟通的技术愿景，这个愿景应该可以帮助你满足客户和组织的需求。
- 同理心：理解你所做的决定对客户和同事带来的影响。
- 合作：和尽量多的同事进行沟通，从而更好地对愿景进行定义、修订以及执行。
- 适应性：确保在你的客户和组织需要的时候调整技术愿景。
- 自治性：在标准化和团队自治之间寻找一个正确的平衡点。
- 治理：确保系统按照技术愿景的实现。
