与建造建筑物相比，在软件中我们会面临大量的需求变更，使用的工具和技术也具有多样性。软件并不是在某个时间点之后就不再变化，甚至在发布到生产环境之后，软件还能继续演化。

        架构师的职责更像是一个城市规划师，城市规划师的职责是优化城镇布局，使其更易于现有居民生活，同时也会考虑一些未来的因素。为了达到这个目的，他需要收集各种各样的信息，他不会直接说“在那个地方盖一栋这样的楼”，相反他会对城市进行分区，将城市的某个部分规划为工业区，另外一部分规划为居民区，然后其他人决定具体盖什么建筑物，当然该盖具体的建筑要受到约束，比如工厂一定要盖在工业区。

      架构师应该像城市规划师那样专注于大方向上，只有在很有限的情况下参与到非常具体的细节实现中来。

       区域的概念对应软件，就是我们服务的边界，或者是一些粗粒度的服务群组，作为架构师应该过多关注服务之间如何交互。在区域之间，或者说传统架构图中的框图之间，我们需要非常小心，因为在这些地方犯的错误会很难纠正。

        做系统设计方面的决定通常都是在做取舍，有时候做决策所需要的信息很容易获取，有时候却难以获取，下面的方法可以指导我们如何设计。

        战略目标关心的是公司的走向以及如何才能让自己的客户满意，通常有公司高层制定。这些是公司的业务愿景，通常与技术无关，需要充分给业务部门交互，才能制定好。比如一个战略目标可以是:“缩短新功能上线周期”。

       为了和战略目标保持一致，我们需要指定一些具体的规则，并称之为原则。一般来讲，原则做好不要超过10个，或者能够写在一张海报上，让大家能够记住。另外，约束是很难（或者不可能）改变的，但是原则也是我们自己决定的，让它们分离可以使用户很清楚哪些不能改变；但是把原则和约束放在同一个列表中也是有好处的，可以让我们不时回顾一些这些约束是否真的不可改变。比如一个针对战略目标“缩短新功能上线周期”的原则，可以是“交付团队应该对整个软件生命周期有完全的控制权”。

        我们通过相应的实践来保证原则能够实施，这些实践能够指导我们如何完成任务。通常这些实践是技术相关的，而且是比较底层的。由于偏技术层面，所以其改变的频率会高于原则。比如针对原则“交付团队应该对整个软件生命周期有完全的控制权”的实践之一是“所有的服务都部署在不同的AWS账户中，从而可以提供资源的自助管理和其他团队的隔离”。

        监控可以清晰地描绘出跨服务系统的健康状态，监控必须在系统级别而非单个服务级别进行考虑。

        选用少数几种明确的接口技术有助于新的服务消费者的集成。使用一种标准方式很好，二种也不太坏，但不能过多。

        没有很好处理下游错误请求的服务越多，我们的系统就会越脆弱。服务要很好地处理以下这些请求：正常并且被正确处理的请求、错误请求并且服务识别出了它是错误的，但什么也没做、被访问的服务宕机了，所以无法判读请求是否正常。

        为团队提供服务范例（最好来自真实项目），这样可以供团队成员模仿，来对各个服务的代码达成共识，并保证系统的一些原则和实践得以体现。

        针对自己的开发实践裁剪出一个服务代码模板（所有核心属性的代码都是现成的），不但可以提高开发速度，还可以保证服务的质量。

        所有偏离技术愿景来实现短期利益的取舍，都会为长期带来付出的代价，这些就像现实中的债务一样，被称为技术债务，累积的技术债务是需要偿还的，架构师应该从更高的层次出发，理解如何做权衡，理解债务的层次及其对系统的影响，可以让团队自行决定如何偿还债务，也可以将团队维护一个债务列表，并且定期回顾。

        原则和实践可以知道我们如何构建系统，如果我们决定针对某个规则破一次例，就应该把它记下来。如果这样的例外出现了多次，就可以通过修改原则和实践的方式把我们的理解固化下来。

        架构师要确保有一组可以指导开发的原则，这些原则要与组织的战略相符。确保以这些原则为指导衍生出来的实践不会对开发人员带来痛苦，需要了解新技术，需要知道在什么时候做怎样的取舍，并且尽量让开发同事理解和支持这种取舍。这些的前提是治理，治理是一个小组活动，需要有技术专家领导并且有一线人员参与，负责跟踪和管理技术风险。理想的情况是架构师领导治理小组，治理小组有每个交付团队的开发负责人参加，架构师负责该小组的运作，整个小组都要对治理负责，这样可以保证信息从开发团队顺利流入小组，从而保证小组做出更合理的决定。

       帮助团队成长。微服务架构中存在多个自治的代码库，每个代码库都有自己的独立生命周期，这给更多人提供了对单个服务负责的机会，而当这些人在单个服务上面得到足够锻炼之后，就可以给他们更多的责任，从而帮助他们逐步达成自己的职业目标，同时通过分担职责也可以防止某一个人的负担过重。