Prepare to Pick Two
2015-08-27 09:33
330 查看

SoMETiMES ACCEpTing A ConSTRAinT or giving up on a property can lead to a better architecture, one that is easier and less expensive to build and run. Like buses, desirable properties tend to come in threes, and trying to define and build a system that supports all three can result in a system that does noth- ing especially well.
A famous example is Brewer’s conjecture, also known as Consistency, Avail- ability, and Partitioning (CAP), which states that there are three properties that are commonly desired in a distributed system—consistency, availability, and partition tolerance—and that it is impossible to achieve all three. Trying to have all three will drastically increase the engineering costs and typically increase complexity without actually achieving the desired effect or business goal. If your data must be available and distributed, achieving consistency becomes increasingly expensive and eventually impossible. Likewise, if the system must be distributed and consistent, ensuring consistency will lead at first to latency and performance problems and eventually to unavailability since the system cannot be exposed as it tries to reaches agreement.
It’s often the case that one or more properties are considered inviolate: data cannot be duplicated, all writes must be transactional, the system must be

100% available, calls must be asynchronous, there must be no single point of failure, everything must be extensible, and so on. Apart from being naïve, treating properties as religious artifacts will stop you from thinking about the problem at hand. We start to talk about architectural deviation instead of prin- cipled design and we confuse dogmatism with good governance. Instead we should ask, why must these properties hold? What benefit is to be had by doing so? When are these properties desirable? How can we break up the system to achieve a better result? Be ever the skeptic, because architectural dogma tends to undermine delivery. The inevitability of such tradeoffs is one of the most difficult things to accept in software development, not just as architects, but also as developers and stakeholders. But we should cherish them; it’s far better than having limitless choice, and accepting tradeoffs often induces a creative and inventive result.
Bill de hÓra is chief architect with NewBay Software, where he works on large scale web and mobile systems. He is co-editor of the Atom Publishing Protocol and previously served on the W3C RDF Working Group. He is a recognized expert on REST style and message-passing architectures and protocol design.
Prepare to Pick Two
Bill de hÓraSoMETiMES ACCEpTing A ConSTRAinT or giving up on a property can lead to a better architecture, one that is easier and less expensive to build and run. Like buses, desirable properties tend to come in threes, and trying to define and build a system that supports all three can result in a system that does noth- ing especially well.
A famous example is Brewer’s conjecture, also known as Consistency, Avail- ability, and Partitioning (CAP), which states that there are three properties that are commonly desired in a distributed system—consistency, availability, and partition tolerance—and that it is impossible to achieve all three. Trying to have all three will drastically increase the engineering costs and typically increase complexity without actually achieving the desired effect or business goal. If your data must be available and distributed, achieving consistency becomes increasingly expensive and eventually impossible. Likewise, if the system must be distributed and consistent, ensuring consistency will lead at first to latency and performance problems and eventually to unavailability since the system cannot be exposed as it tries to reaches agreement.
It’s often the case that one or more properties are considered inviolate: data cannot be duplicated, all writes must be transactional, the system must be

100% available, calls must be asynchronous, there must be no single point of failure, everything must be extensible, and so on. Apart from being naïve, treating properties as religious artifacts will stop you from thinking about the problem at hand. We start to talk about architectural deviation instead of prin- cipled design and we confuse dogmatism with good governance. Instead we should ask, why must these properties hold? What benefit is to be had by doing so? When are these properties desirable? How can we break up the system to achieve a better result? Be ever the skeptic, because architectural dogma tends to undermine delivery. The inevitability of such tradeoffs is one of the most difficult things to accept in software development, not just as architects, but also as developers and stakeholders. But we should cherish them; it’s far better than having limitless choice, and accepting tradeoffs often induces a creative and inventive result.
Bill de hÓra is chief architect with NewBay Software, where he works on large scale web and mobile systems. He is co-editor of the Atom Publishing Protocol and previously served on the W3C RDF Working Group. He is a recognized expert on REST style and message-passing architectures and protocol design.
相关文章推荐
- TimerTask的小例子
- Cordova集成 jpush之从消息中心打开通知信息跳转
- service XXX does not support chkconfig
- datagridview用虚模式展示大量数据。
- POJ 2299 Ultra-QuickSort(归并排序)
- [笔试]构造函数的执行顺序
- python pandas dataframe 去重函数
- SpringAnnotation之配置AnnotationXML文件
- linux上的压力测试
- SpringMVC总结
- hdu 1203 I NEED A OFFER! <背包的变形>
- hdoj.4165 Pills【卡特兰数列】 2015/08/27
- POJ 2262 Goldbach's Conjecture(数论)
- Effective C++——条款5(第2章)
- J1850 Implement
- ajax异步请求的几种常用方法
- MSSQLSERVER数据库- SQL删除重复数据的五种方式
- DATEDIFF 和 DATEADD
- 数组分组
- Opencv 各种特征点提取和匹配