架构师的素养

2017 年 8 月 28 日 架构文摘 落落落落大大方方

优秀人才不缺工作机会，只缺适合自己的好机会。但是他们往往没有精力从海量机会中找到最适合的那个。
100offer 会对平台上的人才和企业进行严格筛选，让「最好的人才」和「最好的公司」相遇。
扫描下方二维码，注册 100offer，谈谈你对下一份工作的期待。一周内，收到 5-10 个满足你要求的好机会：

软件架构师的首要关注点不是系统的功能。

拿到系统需求时首先考虑的不是页面布局或导航树，而是要考虑谁提供的服务器？运行在WinServer还是Linux？想支持多少用户并发？应用需要什么样的安全性？应用运行在公网还是内网？

成功架构师的两项关键实践：让利益相关人参与以及同时关注功能和品质。

功能性：产品向他的用户提供哪些功能？

可变性：软件将来可能需要哪些变化？哪些改变不太可能发生，不需要特别容易进行这些改变？

性能：产品将打到怎么样的性能

容量：多少用户将并发使用系统？系统为用户存储多少数据？

生态系统：在部署环境时，系统将与其他系统进行哪些交互？

模块化：如何编写软件的任务分解为工作指派，特别是这些模块可以独立开发，并能够准确而容易的满足彼此需要？

可构建性：如何将软件构建为一组组件，并能够独立实现和验证这些组件？哪些组件应该复用其他产品，哪些用过从外部供应商获得？

产品化：如果产品将以几种变体的形式存在，如何开发一个产品线，并利用这些变体的共性？产品线中的产品以怎样的步骤开发，在创建一条产品线时，要进行哪些投资？开发产品线中不同变体的选择，预期会得到怎样的回报？特别是是否可能先开发最小的有用产品再进行扩展？

安全性：产品是否需要用户认证或必须限制对数据的访问？数据安全性如何保证？如何抵挡DDOS攻击或其他攻击？

架构师玩的是折中游戏，对于一组给定的功能需求和品质要求，没有唯一的正确架构和唯一的正确答案。

架构评估的两种方式

第一种通过性能建模来评估吞吐量和伸缩性，通过失效树模型来评估可靠性和可访问性。其他类型的模型包括复杂性和耦合指标，用于评估可变性和可维护性。

第二种就是通过对架构师提出质询来评估架构，质询方法的另一种变体是架构折中分析方法，它寻找架构不能满足品质关注点的风险。

在设计系统架构时要确保系统在伸缩时的弹性。总体架构必须是一个分布式系统，可以随着请求增长而添加机器，当请求下降时移走机器。

企业中的一般经验法则是90%的数据访问都是只读的，大多数任务会读取大量数据，然后再改写少量数据。在MMO和虚拟世界的环境中，大多数任务只访问服务器上少量的状态数据，但在他访问的数据中，大约一半会被改写。

企业环境中，目标是任务管理，如果总吞吐量得到改进，在处理中有一点延迟是可以接受的。MMO和虚拟世界环境中延迟则是最大的敌人。

MMO应对数量巨大的用户方法目前有两大类。

第一类是基于地理位置实现，设计成包含一组不同的区域，每个区域运行在一台服务器上。例如虚拟世界中的某个主城在一台服务器上，一个小镇在另一台服务器上。游戏设计视图让每个区域无关，限定地理区域能实现自我限制，主城延迟的时候玩家就会到小镇中体验游戏。将不同地理区域分配给不同服务器来实现伸缩的方法有一个问题，就是必须在编写时决定哪些区域放在哪些服务器上。添加容易修改则可能需要改动代码。猜测魔兽世界就是使用这种方式解决并发量。

第二类是用分区的方法处理游戏中用的拥塞区域。一个分区是该区域的一个副本，运行在自己的服务器上，独立于其他的分区，它代表游戏中相同的部分。缺点是不允许处在不同分区的玩家彼此之间进行交互。游戏不同线路平行分区就是这种方式。