关于什么是架构,一种比较通俗的说法是 “最高层次的规划,难以改变的决定”,这些规划和决定奠定了事物未来发展的方向和最终的蓝图。
从这个意义上说,人生规划也是一种架构。选什么学校、学什么专业、进什么公司、找什么对象,过什么样的生活,都是自己人生的架构。
具体到软件架构,维基百科是这样定义的:“有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计”。系统的各个重要组成部分及其关系构成了系统的架构,这些组成部分可以是具体的功能模块,也可以是非功能的设计与决策,他们相互关系组成一个整体,共同构成了软件系统的架构。
架构其实就是把复杂的问题抽象化、简单化,可能你会觉得“说起来容易但做起来难”,如何能快速上手。可以多观察,根据物质决定意识,借助生活真实场景(用户故事,要很多故事)来还原这一系列问题,抓住并提取核心特征。
CPU运算速度>>>>>内存的读写速度>>>>磁盘读写速度
双11期间,对于一些重要的接口(比如帐号的查询接口,店铺首页)做流量控制,超过阈值直接返回失败。 另外对于一些不重要的业务也可以考虑采用降级方案,大促—>邮件系统。根据28原则,提前将大卖家约1W左右在缓存中预热,并设置起止时间,活动期间内这部分大卖家不发交易邮件提醒,以减轻SA邮件服务器的压力。
最大程度保证主链路的可用性,比如我负责交易的下单,而下单过程中有优惠的业务逻辑,此时需要考虑UMP系统挂掉,不会影响用户下单(后面可以通过修改价格弥补),采用的方式是,如果优惠挂掉,重新渲染页面,并增加ump屏蔽标记,下单时会自动屏蔽ump的代码逻辑。 另外还会记录ump系统不可用次数,一定时间内超过阈值,系统会自动报警。
第三方系统可能会不稳定,存在接口超时或宕机,为了增加系统的健壮性,调用接口时设置超时时间以及异常捕获处理。
做好容量规划、系统间强弱依赖关系梳理。 如:冷热数据不同处理,早期的订单采用oracle存储,随着订单的数量越来越多,查询缓慢,考虑数据迁移,引入历史表,将已归档的记录迁移到历史表中。当然最好的方法是分库分表。
相信我们大多数人在儿童时期都喜欢玩乐高积木。乐高积木的真正乐趣和吸引力在于,尽管包装盒外面都带有示意图片,但你最终都可以随心所欲得搭出各种样子或造型。
对 API 的最佳解释就是它们像乐高积木一样。我们可以用创造性的方式来组合它们,而不用在意它们原本的设计和实现意图。
你可以发现很多 API 和乐高积木的相似之处:
乐高和 API 都有超简单的界面/接口,并且借助这样简单的界面/接口,它可以非常直观、容易、快速得构建。
虽然乐高和 API 一样可能附带示意图片或使用文档,大概描述了推荐玩法或用途,但真正令人兴奋的结果或收获恰恰是通过创造力产生的。
让我们仔细地思考下上述的提法。在很多情况下,API 的使用者构建出了 API 的构建者超出预期的服务或产品,API 使用者想要的,和 API 构建者认为使用者想要的,这二者之间通常有个断层。事实也确实如此,在 IoT 领域,我们使用 API 创造出了一些非常有创造性的使用场景。