程序总论
本自具足反求诸己
道生之,德畜之,物形之,势成之。
德之自身,其德乃真。
展开
-
规则 - 保持竞争力
内容:让架构的每个组成部分都有竞争力或认同竞争力。场景:任何在线交付的解决方案。用法:对产品的每个组件,确定团队的责任和该组件的竞争力水平。原因:对客户而言,每个问题都是你的责任。不能怨供应商。你提供的是服务,而非软件。要点:不要把竞争力与自建还是购买或核心还是外围决策混淆。可以购买解决方案,但必须在部署和维护时保持竞争力。事实上,客户要求你这样做。 你可以选择外包和...原创 2018-10-10 08:28:44 · 225 阅读 · 0 评论 -
规则 - 失败乃成功之母
内容:抓住每个机会,尤其是失败的机会,学习经验并吸收教训。场景:不断地从错误和成功中学习。用法:观察客户或者A/B测试验证。建立事后分析过程,在低故障率环境下采用假设失败的方法。原因:做事情不考虑结果或发生事故而没有从中吸取教训,都会错失良机,从而让竞争对手趁机占便宜。最好的经验来自于失败中的错误,而不是成功。要点:要不断努力学习。学习得最好、最快和最频繁的是那些增长最快并且最具有...原创 2018-09-27 06:32:37 · 212 阅读 · 0 评论 -
规则 - 独立对象缓存
内容:在架构中采用单独的对象缓存。场景:任何实施对象缓存的时候。用法:将对象缓存移到自己的服务器上。原因:对象缓存层独立的好处是可以更好地利用内存和CPU资源,并具备可以在其它层之外独立扩展对象缓存的能力。要点:在实施对象缓存时,把服务器配置在现有层如应用服务器上很简单。考虑把对象缓存实施或迁移到自己的层上,以便取得更好的性能和可扩展性。 在监控对象缓存的命中率下降到85%...原创 2018-09-27 06:27:48 · 318 阅读 · 0 评论 -
规则 - 利用对象缓存
内容:实现对象缓存以帮助扩展持久层。场景:任何有重复查询或计算的时候。用法:选择任何开源或有供应商支持的解决方案和应用代码中实现。原因:实施相当简单的对象缓存可以节省大量应用或数据库服务器上的计算资源。要点:在任何重复计算的场合,考虑实施对象缓存,但主要在数据库和应用层之间。 实施步骤:1.要实施之前,要观察数据库CPU和内存的使用率,以及SQL查询排行榜。2.决定...原创 2018-09-27 06:25:02 · 190 阅读 · 0 评论 -
规则 - 利用应用缓存
内容:使用应用缓存以成本效益方式扩展。场景:当需要提高可扩展性和降低成本的时候。用法:要最大化应用缓存的影响,首先分析如何拆分架构。原因:应用缓存提供了以成本效益方式扩展的能力,但是应该与系统架构互补。要点:在实施应用缓存,从成本和可扩展性角度看取得最大效果之前,应该考虑如何沿y轴或者z轴拆分应用。 基本观点:1.如果想以成本效益方式扩展,绝对需要实施应用缓存。...原创 2018-09-27 06:20:56 · 140 阅读 · 0 评论 -
规则 - 利用页面缓存
内容:在网络服务器的前端部署页面缓存。场景:总是。用法:选择缓存的解决方案然后部署。原因:通过缓存和分发以前产生的动态请求降低网络负载,快速响应静态对象请求。要点:页面缓存是减少动态请求的好方法,可以减少客户响应时间,以成本效益方式扩散。 三个要点:1.在网络服务器前面实现页面缓存,有显著的扩展效益。2.使用适当的HTTP头,可以确保内容缓存和结果缓存的最大潜...原创 2018-09-27 06:18:11 · 184 阅读 · 0 评论 -
规则 - 利用Ajax缓存
内容:适当使用HTTP响应头以确保Ajax调用可以缓存。场景:除了因为数据刚刚更新过,所以绝对需要实时数据以外的任何Ajax调用。用法:适当调整Last-Modified、Cache-Control、Expires。原因:减少用户感知的响应时间,增加用户的满意度,提高平台或方案的可扩展性。要点:尽量利用Ajax和缓存Ajax调用以提高用户满意度及可扩展性。 Ajax是一组技...原创 2018-09-27 06:15:20 · 262 阅读 · 0 评论 -
规则 - 灵活管理缓存
内容:使用Expires头来减少请求量,提高系统的可扩张性和性能。场景:所有的对象类型都需要考虑。用法:可以通过应用代码在网络服务器上设置头字节。原因:减少对象请求可提高用户页面性能并减少系统必须处理的单用户请求数。重点:对每类对象(图片、HTML、CSS、javascript、PHP等),根据目标可缓存时间安排最合适其时间长度的头字节。 HTTP提供了比页面meta标签更...原创 2018-09-27 06:12:20 · 231 阅读 · 0 评论 -
规则 - 利用CDN缓存
内容:用CDN(内容分发网络)来减少网站的负载。场景:速度提升和可扩展水平的提高可以平衡额外的成本。用法:大多数CDN借助DNS为网站提供内容。因此可能需要在DNS做些小改动或添加记录,以便把提供内容的网址迁移到新的子域名上。原因:CDN有助于平缓流量高峰,而且常常是网站部分流量扩展比较经济的方法。常用于改善网页下载时间。要点:CDN是快速而且简单的平缓高峰流量和一般流量增长的方式...原创 2018-09-27 06:09:59 · 607 阅读 · 0 评论 -
规则 - 放宽时间约束
内容:尽可能放宽系统中的时间约束。场景:当考虑在用户操作步骤之间,某些项目或对象必须保持某种状态的约束时。用法:放宽业务规则的约束。原因:因为大多数关系型数据库的ACID属性,要扩展带有时间约束的系统难度极高。要点:认真考虑诸如某个产品从用户查看开始,到购买为止的时间约束的必要性。与让用户有些失望相比,系统因为无法扩展而停止服务相比更为严重。 分布式环境中有三个核心要求存在...原创 2018-09-05 08:37:27 · 353 阅读 · 0 评论 -
规则 - 不靠QA发现错误
内容:利用QA降低产品交付成本,提高技术吞吐量,发现质量趋势,减少缺陷,但不提高质量。场景:任何可能的机会下,通过专人聚焦测试而不是写代码以提高效率。利用QA从过去的错误中学习。用法:每当测试活动获得超过一个工程师的价值输出时,就雇佣一个QA人员。原因:降低成本,加快交付速度,减少缺陷重复。要点:因为系统质量无法测试,所以QA不会提高质量。如果使用得到,可以提高生产力,同时降低成本...原创 2018-09-27 06:38:58 · 173 阅读 · 0 评论 -
规则 - 不能回滚注定失败
内容:必须具备代码回滚的能力。场景:确保所有版本的代码都有回滚能力,在准生产或者QA环境演练,必要时在生产环境,必要时在生产环境用它来解决客户问题。用法:清理代码并遵循几个简单步骤以确保可以回滚代码。原因:如果没有经历过无法回滚代码的痛,还继续冒险地“修改-发布”代码,那么你可能会在某个时刻体会到这种痛苦。要点:应用过于复杂或者代码发布太频繁所以不能回滚,这个借口无法接受。稳健的飞...原创 2018-09-27 06:40:43 · 189 阅读 · 0 评论 -
规则 - 从事务处理中清除商务智能
内容:业务系统与产品系统分离、产品智能与数据库系统分离。场景:任何考虑公司内部需求和将数据转入、转出或产品之间转换的时候。用法:把存储过程从数据库移动到应用逻辑。在公司和产品系统之间不做同步调用。原因:把应用逻辑放在数据库中是昂贵而且影响可扩展性。把公司系统和产品系统绑在一起也是昂贵的,同样会影响可扩展性并带来可用性问题。要点:由于许可证和独特的系统特性,扩展数据库和公司内部系统的...原创 2018-10-09 06:41:11 · 154 阅读 · 0 评论 -
规则 - 完善监控
内容:想想在设计时需要考虑什么才能监控应用。场景:每当添加或更改代码库的模块时。用法:在系统中适当埋点以记录事务的时间。原因:深入了解应用的性能有助于在出现故障时回答许多问题。要点:把必须监控应用作为一条架构原则。另外,看看整体监控策略从确保可以回答:“有问题吗?” “问题在哪里?” 和 “什么问题?” 性能指标都会做监控,例如服务器的CPU使用率、自动报警等等,但是业务监...原创 2018-10-09 08:42:02 · 154 阅读 · 0 评论 -
规则 - 分类处理不同负载
内容:通过分区和故障隔离,处理独特的工作负载,以最大的限度地提高整体可用性、可扩展性和成本效益。场景:每当架构中包含分析和产品解决方案时。用法:确保解决方案支持四种基本类型的工作负载:归纳、演绎、批处理、用户交互/OLTP。保证它们彼此故障隔离,每种都存在于自己的故障隔离区内。原因:每种工作负载都有独特的需求和可用性要求。另外,每种都会影响其他的可用性和响应时间。通过把这些工作隔离在不...原创 2018-10-09 08:41:16 · 240 阅读 · 0 评论 -
规则 - 梯级存储策略
内容:将存储成本与数据价值匹配,包括删除价值低于存储成本的数据。场景:在设计讨论期间及数据的整个生命周期,应用于数据及其基础存储设施。用法:使用近因、频率和货币化分析确定数据的价值。将存储成本与数据价值匹配。原因:并非所有的数据对业务都有相似的价值,事实上,随着时间的推移,数据的价值经常下降。因此,我们不应该用单一的存储解决方案以同样的成本存储所有的数据。要点:理解和计算数据的价值...原创 2018-10-09 08:40:32 · 218 阅读 · 0 评论 -
规则 - 警惕第三方方案
内容:扩展自己的系统;不要依赖供应商的解决方案来实现可扩展性。场景:每当考虑是否使用来自供应商的新功能或新产品时。用法:依靠本书的规则来理解如何扩展,尽可能用最简单的方式使用供应商提供的产品或服务。原因:遵循这条规则有三个理由:掌握自己的命运,保持架构简单,降低总的成本。要知道是客户而不是供应商要你对产品的可扩展性和可用性负责。要点:不要依赖供应商的产品、服务或系统功能来扩展。保持...原创 2018-10-09 08:39:46 · 186 阅读 · 0 评论 -
规则 - 避免总线过度拥挤
内容:总线流量仅限于那些价值高于处理成本的事件。场景:在任何消息总线上。用法:以价值和成本判断消息流量。去除低价值、高成本的流量。抽样调整低价值/低成本和高价值/高成本以降低成本。原因:消息流量不是“免费的”,并且对系统提出了昂贵的要求。要点:不要发布一切消息。对流量进行抽样以确保成本与价值之间的平衡。 事情过犹不及。选择合适的消息放置在总线上。当总线上容量不够时,...原创 2018-10-09 08:38:51 · 196 阅读 · 0 评论 -
规则 - 扩展消息总线
内容:同任何物理或逻辑系统一样,消息总线也因为需求而失败。所以它们也需要扩展。场景:每次当消息总线是架构组件的时候。用法:采用AKF的y和z轴拆分原因:确保消息总线可以扩展以满足用户需要。要点:像对待任何其他关键组件那样对待消息总线。在需求到来之前沿y轴或者是z轴扩展。 技术架构中最常见的故障之一:企业服务总线或消息总线的巨大单点故障。就跟我们在现实中开辟了一条大道,这...原创 2018-10-09 08:37:21 · 143 阅读 · 0 评论 -
规则 - 禁用分阶段提交
内容:不要使用分阶段提交协议来存储或处理事务。场景:总是传递或从不使用分阶段提交。用法:不用;采用y轴或在z轴拆分数据存储和处理系统。原因:分阶段提交是一个阻塞协议,它不允许其他事务处理直至其弯沉。要点:不要使用分阶段提交协议作为延长单体数据库生命的简单方法。者可能不利于扩展甚至导致系统更早消亡。 每一个事务都是原子性操作,是独立的,短时的,一次性的。分阶段提交打破了事务的...原创 2018-10-09 06:49:22 · 152 阅读 · 0 评论 -
规则 - 正确使用数据库锁
内容:理解如何使用明锁和监控暗锁。场景:每次采用关系数据库作为解决方案时。用法:在代码审查时注意明锁。监控数据库暗锁,并在必要时进行明确调整以保证适度的吞吐量,选择允许锁类型和粒度灵活性的数据库与存储引擎。原因:最大化数据库的并发性和吞吐量。要点:理解锁类型并管理其使用情况,以使数据库吞吐量和并发性最大化。改变锁类型,以便更好的使用数据库,并在成长中拆分数据结构或数据库。确保选择允...原创 2018-10-09 06:46:01 · 252 阅读 · 0 评论 -
规则 - 注意昂贵的关系
内容:注意数据模型中的关系。场景:当设计数据模型、添加表/列、写查询语句或从长计议考虑实体之间的关系会如何影响效率和扩展性。用法:当设计数据模型时,考虑数据库分离和未来可能的数据需求。原因:实施之后在修复被破损数据模型的费用是设计过程中修复的100倍。要点:超前考虑,仔细计划数据模型。设计范式时,考虑将来如何拆分数据库和应用系统可能的数据需求。 成本效益是衡量数据库关系的标...原创 2018-10-09 06:45:02 · 157 阅读 · 0 评论 -
规则 - 停止重定向
内容:如果有可能,避免重定向;确实需要时,采用正确的方法。场景:总是。用法:如果需要重定向,考虑通过服务器配置来实现,而不是利用HTML或者其他基于代码的解决方案。原因:总体来说,重定向会延迟用户进程,消耗计算资源,造成错误,不利于页面在搜索引擎中的排名。要点:正确而且仅在必要时使用重定向。 HTTP 3xx状态码中有几段是与重定向相关的。300多项选择(Multipl...原创 2018-09-04 15:42:25 · 479 阅读 · 0 评论 -
规则 - 避免画蛇添足
内容:翻来覆去地检查刚完成的工作或马上读取刚写入的数据。场景:总是。用法:避免为了确认操作是否有效而读取刚写入的数据,如近期处理需要,可把数据存储在本地或分布式缓存。原因:与不太可能出现的操作失败所产生的成本相比,确认操作成本更高,而且这类活动与有效扩张相背离。要点:永远不要为确认操作是否有效而读取刚写入的数据。相信持久层会对写入的相关数据出现无法读取或操作失败时发出通知。通过把数...原创 2018-09-04 15:41:23 · 146 阅读 · 0 评论 -
规则 - 适当使用数据库
内容:当需要ACID属性来保存数据之间的关系和一致性时,可以使用关系型数据库。其他数据的存储需要考虑更适合的工具,如NoSQL DBMS。场景:当在系统结架构中引入新数据或数据结构时。用法:考虑数据量、存储量、响应时间长短、关系和其他因素来选择适当的存储工具。也要考虑数据结构及产品需要对数据进行的管理和操作。原因:关系型数据库提供了高度的事务完整性,但是成本很高,难以扩展,而且与其他许...原创 2018-09-04 15:40:36 · 137 阅读 · 0 评论 -
规则 - 方案中包括扩展
内容:提供及时可扩展性的DID方法场景:所有项目通用,是保证可扩展性的最经济有效的方法(资源和时间)。用法:Design 设计20倍的容量;Implement 实施3倍的容量 ; Deploy 部署1.5倍的容量原因:DID为产品扩展提供了经济、有效、及时的方法。要点:在早期考虑可扩展性可以帮助团队节省时间和金钱。在需求发生大约一个月前实施(写代码),在客户蜂拥而至的几天前部署。...原创 2018-08-24 08:17:25 · 241 阅读 · 0 评论 -
规则 - 避免过度设计
内容:在设计中要警惕复杂的解决方案场景:适用于任何项目,而且应在所有大型、复杂系统或项目的设计过程中使用用法:通过测试同时是否能够轻松理解解决方案,来验证是否存在过度设计原因:复杂的解决方案实施成本过高,而且长期的维护费用昂贵要点:过于复杂的系统限制了可扩展性。简单的系统易维护、易扩展且成本低 过度设计有两大类,一类是产品的设计和实施超过了实际的需求;第二类是完成的产品过于...原创 2018-08-24 08:16:32 · 1672 阅读 · 0 评论 -
从设计模式怎样提升设计
设计模式是一种非常有用的设计参照,基本上每次去读设计模式的内容总是会获得新的体会。但是有没有新的模式呢?我想,这个大概是有的,不过新的模式产生估计会非常困难。在编码一段时间之后,大概在一年或者两年之后,我们一般都在想,可不可以把编码做的更好一些,让别人更加容易阅读,更加好维护,更加好修改。怀着这种简单的想法,我开始学习怎么去改良代码。设计模式引领我从纯粹的实现到技术设计方面的思考,也同时非常感原创 2017-10-22 10:35:28 · 390 阅读 · 0 评论 -
代码重构之灾
做过很多的项目,最终你会发现其代码质量是非常有问题的。项目的外包制度、不断基于老的代码上做二次开发并高呼“不要重复造轮子”、开发人员的能运行就可以的态度等等不断将项目的代码拖进无底洞,项目的代码急剧扩大,问题却也爆炸性的增长。最近做的项目就是基于老的项目上做新的项目,其中问题很多。问题分析如下:1.总体项目的设计是公共基础+应用部分的功能。应用部分的功能是互不干扰的数据流,不做每个应用的过原创 2017-10-02 10:23:32 · 520 阅读 · 0 评论 -
资源预算和项目约束
我们做每一件事情的时候,总是或多或少的考虑的成本问题,只有当觉得很划算的时候,才会将打算原创 2017-09-17 09:12:59 · 1513 阅读 · 0 评论 -
个人风格在软件领域的形象
最近在看一些软件设计部分美学和风格的资料,同时也在看一个项目的源代码。两方面相互印证,得到一些新的见解。通俗的表述风格在各行各业的表现就是这个人在处理工作的时候一些个人偏好或者习惯形成的个人印记,非常独特的哪种,虽然比较浅的印记可能辨别不出是谁的,不过至少可以区分出来与别的印记是不同的。当然了,最好的印记就是个人在工作中或者作品中留下的个人名片了。通常新人是没有这种印记的,各行各业资深的人都会有这原创 2017-09-23 12:54:10 · 366 阅读 · 0 评论 -
协作设计与团队工作
现在的设计工作、软件工程已经变得非常的复杂,单人在这种任务面前已经变得无法胜任了。但是团队工作在解决这种大型工程的时候,又有一些什么样的问题呢?1.维持一个软件工程的核心概念统一问题当任务从单人转向多人,从内核逐渐分解到外围的时候,我们无法保证每个团队里面的人都知道他负责这一块工作到底是干什么的。这个时候,我们必须在整个团队的关键节点上的负责人知道这个节点往下的工作内容什么样的,允许的和不原创 2017-08-27 14:17:33 · 361 阅读 · 0 评论 -
设计的理念
今天在阅读《设计原本》的第一章的时候,看到一个名词“设计理念”的时候,十分惊喜。如果只是说设计本身的话,它可以看做是“一个受造的事物”,当设计作为动词的时候,就是与这个事物相关的设计过程。这个看到这里其实并没有让我感到很惊喜,但是当看到“设计理念”的时候,我觉得今晚的书没有白看。设计理念是具备设计整体的完整概念,是整个设计产生过程围绕的概念上的统一性。这段话还是很抽象。举一个比较实际点原创 2017-07-26 22:10:43 · 475 阅读 · 1 评论 -
设计的理性模型
理性模型,理想的设计过程模型,它具有以下部分:1.目标2.必要条件3.效用函数4.约束条件,包括预算等5.决策的设计树until enough or not allowed do another design to improve until design end while design is good enough原创 2017-08-02 22:55:13 · 763 阅读 · 0 评论 -
规则 - 减少域名解析
内容:从用户角度减少域名解析次数场景:对性能敏感的所有网页用法:尽量减少下载页面所需的域名解析次数,但要保持与浏览器的并发连接平衡原因:域名解析耗时而且大量的解析会影响用户体验要点:减少对象、任务、计算等是加快页面加载速度的好方法,但要考虑好分工。 这是一个关于性能要求的规则,它是直接面向客户的,是用户体验的要求。根据这个规则使用的场景来说,这个规则只是性能优化的一个方面,...原创 2018-08-24 08:18:38 · 312 阅读 · 0 评论 -
规则 - 减少页面目标
内容:尽可能减少页面上的对象数量场景:对性能敏感的所有页面用法:减少或者合并对象,但要平衡最大并发连接数;寻找机会减轻对象的重量;不断测试确保性能的提升原因:对象数量的多少直接影响网页的下载时间要点:对象和服务对象的方法之间平衡是一门科学,需要不断地测量和调整。这是在客户的易用性、可用性和性能之间的平衡。 与减少域名解析的规则类似,这个是针对页面加载内容的组合。易用性代表了...原创 2018-08-24 08:19:38 · 142 阅读 · 0 评论 -
规则 - 三次简化方案
内容:在设计复杂系统时,从项目的范围、设计和实施角度简化方案场景:当设计复杂系统或产品时,面临着技术和计算资源的限制用法:采用帕累托原则简化范围;考虑成本优化和可扩展性来简化设计;要考他人的经验来简化部署原因:只聚焦“不过度复杂”并不能解决需求或历史发展与变革中的各种问题要点:在产品研发的各个阶段都要做好简化 本原则聚焦于简化包括从感知需求到实际设计和实施在内的一切。本原则...原创 2018-08-24 08:20:31 · 147 阅读 · 0 评论 -
规则 - 托管方案扩展
内容:把系统部署到三个或更多活的数据中心,以降低总体成本、增加可用性并实现灾难恢复。数据中心可以是自有设施、托管、云计算实例。场景:任何正在考虑添加灾难恢复数据中心(冷备)的快速增长的业务,或希望通过三数据中心方案优化成本的成熟业务。用法:根据AKF扩展立方体来扩展数据。以“多活”方式配置系统。使用Iaas/Paas来解决突发容量问题,新投资或者作为三数据中心方案的一部分。原因:数据中...原创 2018-09-04 15:39:53 · 228 阅读 · 0 评论 -
规则 - 积极使用日志文件
内容:使用应用日志文件来诊断和预防问题。场景:制定监控日志文件的过程,迫使人们对发现的问题采取行动。用法:使用任何监控工具,从自定义脚本到Splunk或者ELK框架,监控应用日志中的错误。导出这些错误信息,然后安排资源去确定和解决问题。原因:日志文件是有关应用执行的绝好信息来源,不要轻易抛弃。要点:若充分利用好日志文件,生产问题将越来越少,且当问题出现时刻迅速定位解决。 日...原创 2018-09-04 15:38:49 · 91 阅读 · 0 评论 -
规则 - 谨慎使用防火墙
内容:只有在显著降低风险时才使用防火墙。要认识到防火墙会导致可扩展性和可用性问题。场景:总是。用法:可以使用防火墙满足关键PII、PCI(支付卡行业)的合规性要求。不要在低价值的静态内容防护上。原因:防火墙降低可用性病引起不必要的可扩展性瓶颈。要点:防火墙虽有用,但常被滥用,设计和实施不当会带来可用性和可扩展性问题。 防火墙是为了提高信息安全,降低数据安全风险的工具。...原创 2018-09-04 15:37:40 · 234 阅读 · 0 评论