论架构师的素养

jiagoushi.jpg

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

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

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

功能性:产品向他的用户提供哪些功能?
可变性:软件将来可能需要哪些变化?哪些改变不太可能发生,不需要特别容易进行这些改变?
性能:产品将打到怎么样的性能
容量:多少用户将并发使用系统?系统为用户存储多少数据?
生态系统:在部署环境时,系统将与其他系统进行哪些交互?
模块化:如何编写软件的任务分解为工作指派,特别是这些模块可以独立开发,并能够准确而容易的满足彼此需要?
可构建性:如何将软件构建为一组组件,并能够独立实现和验证这些组件?哪些组件应该复用其他产品,哪些用过从外部供应商获得?
产品化:如果产品将以几种变体的形式存在,如何开发一个产品线,并利用这些变体的共性?产品线中的产品以怎样的步骤开发,在创建一条产品线时,要进行哪些投资?开发产品线中不同变体的选择,预期会得到怎样的回报?特别是是否可能先开发最小的有用产品再进行扩展?
安全性:产品是否需要用户认证或必须限制对数据的访问?数据安全性如何保证?如何抵挡DDOS攻击或其他攻击?
架构师玩的是折中游戏,对于一组给定的功能需求和品质要求,没有唯一的正确架构和唯一的正确答案。

架构评估的两种方式

第一种通过性能建模来评估吞吐量和伸缩性,通过失效树模型来评估可靠性和可访问性。其他类型的模型包括复杂性和耦合指标,用于评估可变性和可维护性。
第二种就是通过对架构师提出质询来评估架构,质询方法的另一种变体是架构折中分析方法,它寻找架构不能满足品质关注点的风险。

在设计系统架构时要确保系统在伸缩时的弹性。总体架构必须是一个分布式系统,可以随着请求增长而添加机器,当请求下降时移走机器。
企业中的一般经验法则是90%的数据访问都是只读的,大多数任务会读取大量数据,然后再改写少量数据。在MMO和虚拟世界的环境中,大多数任务只访问服务器上少量的状态数据,但在他访问的数据中,大约一半会被改写。
企业环境中,目标是任务管理,如果总吞吐量得到改进,在处理中有一点延迟是可以接受的。MMO和虚拟世界环境中延迟则是最大的敌人。

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

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

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

来源:简书
地址:http://www.jianshu.com/p/96f6430c6c70

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/256593.html

(0)
上一篇 2022年5月18日
下一篇 2022年5月18日

相关推荐

发表回复

登录后才能评论