演化式架构师

来自于《微服务设计》的读书笔记。

1、不准确的比较

你总提及的那个词，它的含义与你想表达的意思并不一样。

我们认为架构师就是确保团队有着共同的技术愿景，以帮助向客户交付他们需要的系统，架构在其中起到战略规划的作用，可是架构师这个职位很微妙，需要很出色的人才来担任，但是也是一个不好胜任的职位。

相比于其他行业的发展，整个计算的真正发展不过百年，因此很多时候其实都还在处于摸索的状态，需要在已经完善的行业中进行寻找，帮助别人去理解我们在做的事情，因为处于一个中间的状态，不为大多数人所熟知内部的运作机理，就像大家都在使用 WEB 进行浏览上网，但是其中的运行逻辑是不被大多数用户知道的（当然你作为开发的工程师是了解这些的，不然也不会让你来负责研发的任务）。

我们常常把自己比作 工程师 或者是 建筑师 ，但实际上相差很大，他们所具备的精确性和纪律性是我们遥不可及的，而且他们在社会中的重要性也很容易理解。就像一个建筑师在设计一栋大楼时，他需要为这栋大楼的安全所负法律责任的，而且一建的资格证书有多难考这个就不用说了吧。相比之下互联网行业的低门槛，就显得手里面的那些计算机技能证书那么的不值钱，因为我们对什么是好的知之甚少。

约束不同

建筑师这类的人员需要提前清楚自己需要做什么，但是对于我们而言很多时候同用户的交互是不清楚需要实现什么的（这个也有办法解决，也就是后面我们将会谈及的领域驱动设计，能在这样的规范之下完成概念的统一）。
标准不同

建筑是要确保的高质量可用的，历史上看来建筑出事的事件也比较少的，但是在软件行业，风险是时时刻刻都在发生着的，这样的约束对于架构来说就有点过于苛刻了。
效果不同

建筑师需要做好详细的计划然后所有的施工都会按照这个计划来走，这种趋于完美的设计稿在软件中也不存在（除非那种已经有过实践经验的完整系统开发），我们不能把未来的所有风险都给预估到，而前期就注重完美的图表的设计实现起来将会遇见很大的麻烦，也就是需要在实践中不停的完善设计。

2、架构演化视角

一个已经创建好的软件并不是不会改变的，在业务支持上或者是用户需求的变更上，我们需要提供更好的支持也就会对软件进行维护修改，所以一开始就完美的系统是不存在的，只有通过刚开始的一个小框架慢慢的演化成为一个正确的系统。

2.1、一个比喻

上面说到我们用 建筑师 来比喻 架构师 这样的形容是不恰当的，但是有一个角色就很相似，那就是 城市规划师 。相信大家从这个名词中就能解读出他的职能含义了，优化城镇布局使之更加适用于人们的日常生活，并考虑到未来的一些因素影响。

城市规划师可能会说在这个区域修建一个居民楼，在另外一个地方创建一个办公大楼，但是你说在居民楼的旁边创建一个化工厂，这明显是不会被规划的。城市规划师更多的是考虑人和公共设施如何从一个区域移动到另外一个区域，而不是具体在某个区域中发生的事情。

架构师做的也是这样的活，我们需要有这样的一个功能来支撑上游服务的发布，但是怎么实现、使用什么样的开发语言和技术不用管，那是研发人员的具体开展活动。架构师设计的一个系统应该让所有用户使用起来都很开心，这里说的用户值得不仅是业务用户，还有开发、运维人员等等，这点来说的话就是 架构师的职责之一就是保证该系统适合开发人员在其上进行工作 。

2.2、一个对比

城市规划师操作的是地面的分区，那架构师操作的是什么呢，就是我们的服务边界，或者说是一些粗粒度的服务群组。也就是说我们应该更加注重服务之间的交互、保证能对整个系统的健康状态进行监控，至于服务具体怎么实现，不应该花费太多的精力，微服务就是要使团队的自治性最大化。

允许每个服务内部使用不同的技术来进行研发任务，但是技术的种类也不应该过于太多，这样对于人员的招聘或者说岗位之间的调换都是很困难的。还有一个就是服务之间的共同特征，子啊保持通信上同组内的服务要一致，不能出现一个使用 RPC 、一个使用 REST 、另一个使用 Java RMI 这种情况，不利于彼此之间的调试。这也就是为什么需要关注服务之间的交互而不应该担心服务内部实现的原因。

2.3、代码架构师

要想架构出来的一个系统能够充分地对开发人员优化的话，架构师就不能太脱离代码本身的实现，即使现在的任务已经不是简单的编码了，但是也需要参加到代码的实际编写当中，偶尔也要自己敲一下代码。很多现在对于架构的评价都是一个脱离一线很久的架构师来指导现在的一线开发人员完成开发，这就有点奇怪了。

当然一个架构师手下的团队绝对不会只有一个的，只有一个的也就不足要架构师这个角色出现在团队中了，多团队的时候也需要亲自介入，时间不长，但是需要有沟通，面对面的交流比看代码要更加高效。

3、原则性方法

规则对于智者来说是指导，对愚蠢者来说是遵从。

做系统设计避免不了对于方案、技术的取舍，但是这个过程是不好进行定义的，下面就是一些原则和实践能够帮助我们进行设计。

战略目标

作为架构师考虑这个东西就有点太宽了，这应该在公司的视角出发，层次比较高，我们只需要保证自己的方向和这个战略是一致的就可以了。
原则

为了保证和更大的目标一致，需要指定一些小规则来进行约束，俗话说没有规矩不成方圆，但是原则也需要和自己的团队相适应，别目标是需要快速交付搞个必须使用难点技术这样的原则。

可以借鉴优秀的架构设定的规则，可能团队不适用，原则也不宜太多，太多了限制了团队内部的一个自我发展，重叠冲突的可能性也会增大，适得其反。
实践

实践是检验真理的唯一标准，既然制定了原则就要有实践可以巩固这个原则，确保这个原则能够得到实施。这些实践一般都是最底层的能够帮助指导我们如何完成任务，通常都是和技术相关联的，所以人呢一个开发人员都能够理解。

4、要求的标准

同类的系统之间允许多少的可变性呢，这是一个很重要的因素，因此我们需要识别出各个服务之间共同遵守通用规则。

监控、日志

在复杂的微服务调度链路中，我们需要清晰的感知跨服务系统之间的健康状态，这样才能确保整个系统服务的正常调用，同时也为我们在发生错误时能够快速的定位到问题发生的服务节点，从而调试维护。
接口

内部虽然允许不同服务之间的技术栈不同，但是对外的接口要保持一致，有利于不同团队之间的交流沟通，也减少后期的维护成本。
架构安全

一个下游服务的异常可能会波及整个上游的服务列表，因此服务之间需要进行隔离，同时使用线程池、异常熔断这样的机制来保证异常可控同时不影响其他服务的正常调度。