数据库驱动应用程序中影响性能的反模式
关于ORMapping的一些负面因素的介绍, 个人认为当性能不是关键问题的时候, ORMapping 还是比较好的,可以实现快速的开发,快速部署, 由于其对数据库的封装,也带来部分问题, 牺牲掉数据库在连接,查询方面的效率..
Web开发必知的八种隔离级别
对ACID中的I(Isolation)的8种隔离级别的简单介绍,开发与数据库从业人员都有需要深入了解.
可伸缩性的最差实践
介绍可伸缩性架构设计时应该避免的诸多问题,如所有问题都依赖于一个工具集,如对资源的滥用..
一种正规的性能调优方法：基于等待的调优
类似于Oracle的Wait Interface Based优化,通过使用Instrument收集到系统的开销的详细信息, 并针对等待比较严重的部分进行优化,个人觉得具体可以参考Optimizing Oracle Performance里面的Rmethod优化方法.
构建的可伸缩性和达到的性能：一个虚拟座谈会
倾听多位资深架构师关于架构的分享..
关于性能与可伸缩性的概念.性能与可伸缩性息息相关,但是两个是完全不同的概念,性能更关乎体验,可伸缩性更关乎设计与部署
Randy：我同意独立于任何特定语言或框架来讨论伸缩性问题确实很有价值——不管实现策略如何，模式都是一样的。可是，首先让我们确保自己已经把性能和可伸缩性区分开了。性能是服务于一个单独请求时的资源使用问题。可伸缩性是当要服务更多（或更大）请求时资源消费量如何随之增长的问题。
它们是相关的，但是不是同一件事情:-)。幸运的是，许多改善其中一个问题的方法通常也会改善另一个问题。但是，速度非常快的系统可能并不是最具伸缩性的系统，反之亦然。
FiveRuns：我们关心性能、可伸缩性、可用性的对比。我们把性能定义为一个操作（或一些操作）如何快速地完成，比如，响应时间、每秒事件处理的数量等等；而可伸缩性——就是应用怎样很好地按比例扩大规模以应对更大的使用需求（比如，用户数、请求速度、数据容量）。
关于性能诊断,特别是紧急状况下的性能诊断,有几点基本要求,系统已经做好基本的Instrument,有比较好的Sence(通常要求对业务有很好的理解,有足够多的现场处理经验,以及相应的知识集)
Randy：通常我们会从注意到问题的地方开始，然后向前追溯。在应用栈的所有层次所进行的监测/勘测得越多，就越容易这样做。它还可以帮助有各种学科专长团队里的人们来检查这个问题。
性能因为更多关乎体验,关乎感觉,要很好的检测,就需要建立一些基本的基线, 是否达到标准,具体达到什么样的标准..
FiveRuns：我们得补充一下，适当地建立一个基线是很重要的：一个已知的好的性能表现。并且试图梳理出任何交织于最终用户功能瑕疵的性能问题——有时这些瑕疵看起来只和功能有关，但实际上也包含了性能问题。
Randy：性能绝对是基础。差的性能直接反映了底层基础架构的花销，以及用户的体验。这两者都是底线。一个性能低于预期的应用不是“完成”了的应用，一个缺乏必须功能的应用同样是没有完成的。
FiveRuns：感知的性能是最终用户感觉得到的，因此最应该修正。可是我认为感知的性能是很难测量的—— 即，它是依赖于上下文的，作为观察者，我们不能总是访问同一个上下文环境，而且我们不可能控制组成上下文的所有东西。
Randy：这两者都重要:-)。感知的性能影响了用户体验，而所谓的真实性能会影响成本。这最终就是一个业务决策：此刻最大的痛苦是什么，因此要看哪个相对更优先。
关于新技术的选择,不要盲目的跟进潮流,要仔细分析自己的业务,哪些是可以适用,哪些不能随便调整.
FiveRuns：作为这种产品的制造者，我们对这个问题特别感兴趣！我们认为它是好事——它鼓励创新并给我们带来新的思路。但是我们专注于使用最好的工具组合——新的不见得就是好的。
Randy：有选择是好事情。这取决于你怎么去选择。追赶潮流此刻不再比顽固坚持不能工作的东西更有生产效率。我要说的是在一个像eBay这样24×7都要运转的站点，我们在使用经证明是好的技术时需要非常小心。这是我们对公司的责任。在我们考虑引入任何新东西的时候，在我们考虑将其应用到站点之前都要经过非常广泛的评估。
Blaine：你只能通过使用软件实现伸缩性。“语言是不能伸缩的。框架是不能伸缩的。而架构是可以伸缩的。”
伸缩性是一个社会问题。协调你的业务、操作和工程师们是极其关键的，如果你在这方面不成功，你实现伸缩性的努力也会失败。如果你的公司不理解需要多方协调以培育成功，那么你也会失败。YouTube正是通过正确的处理这一社会问题实现了伸缩性。他们购买服务器、有一个好的投资计划、有足够的带宽。他们选择一件事情，把它做好，以组织的方式决策伸缩性，在天才工程师们的努力下，伸缩性如魔术般被实现了。
FiveRuns：性能改进/伸缩性提升是一件“容易”的事情——修正性能或伸缩性问题不总是像外界看得那么简单——很容易因此受到指责且很难真正解决“所有”给定的约束。以我们的经验，修正性能和伸缩性问题需要对技术和问题领域两方面都有深入了解和经验。
Randy：经常被曲解的是性能和可伸缩性这两者间的区别
架构师修炼之道
InfoQ几个编辑眼中的架构师. 涉及架构师的工作范围,架构师应该具备的技能与素质,个人感觉还是上次给出的51CTO的那个链接总结的更好一点..
赵劼：在我看来，一个合格的架构师需要具备开放的眼光，各种平台、系统、项目随手拈来皆可组合，唯一的目标则是针对合适的环境选择合适的做法，这显然需要在成本和质量之间进行权衡。作为一个架构师，应该具有很好的“弹性”，在真正的环境中，很少会遇见与过去一模一样的情况，因此也需要架构师能够大胆尝试，灵活应对，使用踏实而严谨的做法来进行推测。一个架构师也必须有着足够的沟通和交流能力，把自己的想法使用合适的方式告诉别人，并且根据别人的反馈进行不断调整自己的观点。没有东西是永远正确的，但是一个人往往会倾向于自己的结论，而作为一个合格的架构师，需要有能力认识到自己存在的缺陷，使用各种方式进行弥补。
宋玮：扩充知识面，学习了解众多技术及框架的特点和适用范围。了解非功能特性的相关技术和方法，包括可用性、容错性、可扩展性、可伸缩性等等；了解系统安全性方面的技术和框架以及系统性能和状态监测方面的知识及工具。除了技术方面，还架构师还应扩展自身的业务知识，不断提高业务分析能力。想要做到持续不断的学习，保持对各种技术、框架、产品的浓厚兴趣是必不可少的，另外还要掌握他们各自的优缺点及相应的适用场景。
李明：我觉得这个问题可以从两个方面去谈。一方面，架构师要紧跟技术潮流，了解技术的发展和趋势，利用新技术、新方法来提升团队的生产力，将技术转化为收益。…..。而另一方面，架构师要培养自己的专业领域。虽然从技术的层面上说，很多解决方案放之四海而皆准。但是，从业务的角度来说，很多行业的解决方案放到另外一个行业中，未必行得通。这就要求了架构师必须对所属行业的业务十分了解才行，这也是一个平日里需要修炼的地方。
最近评论