演化式架构师
1、架构师含义
与建造建筑物相比,在软件中我们会面临大量的需求变更,使用的工具和技术也具有多样性。软件并不是在某个时间点之后就不再变化,甚至在发布到生产环境之后,软件还能继续演化。
架构师的职责更像是一个城市规划师,城市规划师的职责是优化城镇布局,使其更易于现有居民生活,同时也会考虑一些未来的因素。为了达到这个目的,他需要收集各种各样的信息,他不会直接说“在那个地方盖一栋这样的楼”,相反他会对城市进行分区,将城市的某个部分规划为工业区,另外一部分规划为居民区,然后其他人决定具体盖什么建筑物,当然该盖具体的建筑要受到约束,比如工厂一定要盖在工业区。
架构师应该像城市规划师那样专注于大方向上,只有在很有限的情况下参与到非常具体的细节实现中来。
2、分区
区域的概念对应软件,就是我们服务的边界,或者是一些粗粒度的服务群组,作为架构师应该过多关注服务之间如何交互。在区域之间,或者说传统架构图中的框图之间,我们需要非常小心,因为在这些地方犯的错误会很难纠正。
3、设计的原则性方法
做系统设计方面的决定通常都是在做取舍,有时候做决策所需要的信息很容易获取,有时候却难以获取,下面的方法可以指导我们如何设计。
(1)、战略目标
战略目标关心的是公司的走向以及如何才能让自己的客户满意,通常有公司高层制定。这些是公司的业务愿景,通常与技术无关,需要充分给业务部门交互,才能制定好。比如一个战略目标可以是:“缩短新功能上线周期”。
(2)、原则
为了和战略目标保持一致,我们需要指定一些具体的规则,并称之为原则。一般来讲,原则做好不要超过10个,或者能够写在一张海报上,让大家能够记住。另外,约束是很难(或者不可能)改变的,但是原则也是我们自己决定的,让它们分离可以使用户很清楚哪些不能改变;但是把原则和约束放在同一个列表中也是有好处的,可以让我们不时回顾一些这些约束是否真的不可改变。比如一个针对战略目标“缩短新功能上线周期”的原则,可以是“交付团队应该对整个软件生命周期有完全的控制权”。
(3)、实践
我们通过相应的实践来保证原则能够实施,这些实践能够指导我们如何完成任务。通常这些实践是技术相关的,而且是比较底层的。由于偏技术层面,所以其改变的频率会高于原则。比如针对原则“交付团队应该对整个软件生命周期有完全的控制权”的实践之一是“所有的服务都部署在不同的AWS账户中,从而可以提供资源的自助管理和其他团队的隔离”。
(4)、将原则和实践相结合
(5)、原则和实践的真实例子
![](https://i-blog.csdnimg.cn/blog_migrate/758aea28cc52e3747ef37478c5c4fe72.png)
4、要求的标准
(1)、监控
监控可以清晰地描绘出跨服务系统的健康状态,监控必须在系统级别而非单个服务级别进行考虑。
(2)、接口
选用少数几种明确的接口技术有助于新的服务消费者的集成。使用一种标准方式很好,二种也不太坏,但不能过多。
(3)、架构安全性
没有很好处理下游错误请求的服务越多,我们的系统就会越脆弱。服务要很好地处理以下这些请求:正常并且被正确处理的请求、错误请求并且服务识别出了它是错误的,但什么也没做、被访问的服务宕机了,所以无法判读请求是否正常。
5、代码治理
(1)、范例
为团队提供服务范例(最好来自真实项目),这样可以供团队成员模仿,来对各个服务的代码达成共识,并保证系统的一些原则和实践得以体现。
(2)、裁剪服务代码模板
针对自己的开发实践裁剪出一个服务代码模板(所有核心属性的代码都是现成的),不但可以提高开发速度,还可以保证服务的质量。
6、技术债务
所有偏离技术愿景来实现短期利益的取舍,都会为长期带来付出的代价,这些就像现实中的债务一样,被称为技术债务,累积的技术债务是需要偿还的,架构师应该从更高的层次出发,理解如何做权衡,理解债务的层次及其对系统的影响,可以让团队自行决定如何偿还债务,也可以将团队维护一个债务列表,并且定期回顾。
7、例外管理
原则和实践可以知道我们如何构建系统,如果我们决定针对某个规则破一次例,就应该把它记下来。如果这样的例外出现了多次,就可以通过修改原则和实践的方式把我们的理解固化下来。
8、集中治理和领导
架构师要确保有一组可以指导开发的原则,这些原则要与组织的战略相符。确保以这些原则为指导衍生出来的实践不会对开发人员带来痛苦,需要了解新技术,需要知道在什么时候做怎样的取舍,并且尽量让开发同事理解和支持这种取舍。这些的前提是治理,治理是一个小组活动,需要有技术专家领导并且有一线人员参与,负责跟踪和管理技术风险。理想的情况是架构师领导治理小组,治理小组有每个交付团队的开发负责人参加,架构师负责该小组的运作,整个小组都要对治理负责,这样可以保证信息从开发团队顺利流入小组,从而保证小组做出更合理的决定。
9、建设团队
帮助团队成长。微服务架构中存在多个自治的代码库,每个代码库都有自己的独立生命周期,这给更多人提供了对单个服务负责的机会,而当这些人在单个服务上面得到足够锻炼之后,就可以给他们更多的责任,从而帮助他们逐步达成自己的职业目标,同时通过分担职责也可以防止某一个人的负担过重。