`
Tonyguxu
  • 浏览: 278541 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

Scalability

 
阅读更多

Scalability

By Julian Browne on April 28, 2008. Filed Under architecturedevelopment

Of all the system qualities debated by architects and developers, scalability is perhaps the one that has the greatest reputation for being mysterious and poorly understood. And if you want to avoid unnecessary work in the future, it's also one of the most important. Except for adding new, or modifying existing, functionality I'd suggest meeting the growth demands of a scaling business ranks highest amongst the work-creating aspects of corporate enterprises.

A clue to the mystery (he somewhat obviously suggests) is in the name - the ability to scale. Scale being a range of values for something, often in a graduated series(分等级), and ability being a measure of capacity or proficiency in operating at the values within the scale. You can simplify capacity and proficiency and just say ease, because that's all businesses really care about. Which gives us two subjective notions to base scalability debates on: exactly what is and isn't easy, and what the strength of belief is as to whether a system can lift itself up the scale when called to at some point in the future.

There are plenty of good definitions out there, such as Werner Vogels' post "A Word on Scalability".

A service is said to be scalable if, when we increase the resources in a system, it results in increased performance in a manner proportional to resources added.

I think that's a rather neat and succinct way to sum up what scalability looks like when it happens, but it doesn't identify what a system that can scale might look like right now. It also doesn't answer the question of whether the resources added would be considered easy or not.

Any system can scale given enough time and money. An extreme example of this would constitute a rewrite, which though inconvenient could still provide a proportional uplift. To be fair, I think Vogels meant his definition to be understood in a continuous sense with a specific meaning to the word resource - double the CPU, double the throughput capability - that sort of thing. And to remain truly scalable, when we double that CPU and reap the commercial rewards of handling twice as much business, we must not see a diminishing capability in other system qualities like data integrity.

Let's design an imaginary web sales solution and see where we might build in scalability as we go. What I hope to show is that much of the range of opinion that might otherwise be brought to bear on those subjective aspects can be avoided early in the process by working through alternative operating models, so that we can meet Vogels' definition without too much hullabaloo.

Our business runs a web site selling fruit and vegetables. In a normal day we sell 500 bananas, but recently a need has been identified for us to scale up to 1000 banana sales per day because we are launching a new campaign in the run up to Christmas, to capitalise on the seasonal trifle-fest.

Our board of directors can empirically say whether or not we are delivering the scale required, because in one day there will be 1000 bananas or more leaving the warehouse and not 500. Although we'll obviously have to track uncompleted orders just to make sure that marketing and the product managers got their predictions correct and orders for 1000+ bananas were actually placed into online baskets.

The first thing to dispense with is any form of rewriting or restructuring our platform. That can't possibly be scalability. If we've written our banana-shop software in all the worst ways, we may have no choice but to respond to the business with a plan, budget and team schedule to meet their scaling needs but that would break the change-partity concept I've talked about before - a measurably good architecture meets a small business change (selling more bananas) with a small technology change (buying more memory, for example).

Change, and therefore scaling, is rarely going to be free but anyone would understand the frustration of a product manager who has to watch all those banana-obsessed English people going to competitor websites because the project to enable them to buy his fruit can't be completed in time to meet the seasonal surge.

Next on our dispensing list is consequential effect. There's no sense being able to handle 1000 banana orders in one day if our customer service application becomes unstable as it receives the order data, thereby reducing our ability to handle calls about cranberry availability. That can't possibly be scalability either.

And finally we must understand that scalability comes in many forms. This example uses an increase inthroughput (bananas per day), but maybe if we examined the requirement more closely we would find that our customers aren't domestic trifle-makers but restaurants hoping to cater to hoards of trifle-loving office workers at the annual Christmas party. Suddenly we're facing more fruit and vegetables per basket in one hour (because restaurants buy all their day's supply between 6am and 7am say). Now we have to scalecapacity in addition to scaling throughput.

So a few points about scalability to bear in mind are:

  • Only local circumstances will define how your business measures ease of scaling - but do make sure it is defined somewhere and not left as a debatable point for later. Clearly, most organisations will put direct and indirect cost at the top of the list, closely followed by timeliness, unless you work in the FMCG world where moving quickly can often trump the initial cost of deployment.

  • Scaling, even easily, against one metric easily may not be of much value if another application or service is negatively impacted.

  • How you scale can be a multidirectional thing. It's easy to capture a requirement badly, which is why I always says you need to be careful of blindly meeting business requirements.

Some of this may sound a little vague, but if scalability were that prescriptive then everyone would be doing it, with ease, and with little debate. I think that what makes scalability seem more dark art than simple checklist is also what makes it an engrossing design feature.

Scalability is an enormous subject. Certainly too big to do any justice to here. A couple of good sources worth reading are Building Scalable Web Sites and sites like High Scalability. It's also true to say that almost every design decsion you make will affect the ease with which you can scale or add to the cost of doing so. But there are some basic techniques and ideas we might have adopted when we designed portal-of-fruit.com such that this banana opportunity could more easily be seized.

Look for Queues

A prime enemy of scalability is the queue. Just as for cars on the roads around the holiday season, anything that causes a small queue in one place can quickly have a knock-on affect in other places. In reality, of course, there are queues and latencies(潜在因素) all through software - if there weren't then everything would complete in zero seconds - but avoiding operations that require blocking should be a primary directive for the critical (i.e. customer affecting) portions of the business process.

Blocking generally takes place whenever something requires consistency in its result. For example, when you hand data over from one application to another you would expect a short pause while the receiver get's itself into a consistent state (i.e. persists the data somewhere so that it can survive a crash). This is good for the sender because it can be confident its data is safe, but the downside is that a queue can form because no other process can use the service while the block is in place.

Granularity(粒度)

To reduce blocking incidents you need to do more in one place (within the same memory space, same process etc), so it's no coincidence that discussions on the topic of transactions and consistency often focus on component scope and granularity. I'm of the school of thought that these things will, by and large, sort themselves out once some other issues are resolved.

One end of the consistency spectrum would be to see the banana order process as one big transaction - the basket is submitted as the initiation of that transaction and, from the user's point of view, it either succeeds or fails (failure here would be because of lack of available stock, insufficient credit, or perhaps a technical reason). And, of course, this view is true from the user's perspective - a customer clicks a button and either gets what they want, or not.

Transactions

Indeed this is closer to the perspective commonly taken by product managers. What they want is to give the customer the best possible experience, and so naturally they see the purchase process in quite literal transactional terms (they might not know they are talking about ACID, but in essence they are). To them the best possible customer experience is for the web site to go away and do all the work and then come back with a nice message for the customer saying all is well and bananas will be leaving to meet them shortly.

And when you analyse our banana order fulfilment business process it is tempting to draw it out as an elongated data flow diagram: validate order, if ok then check stock, if ok then reserve stock, if ok then take payment, if ok then update ERP, if ok then alert warehouse, if ok then confirm order. Clearly each activity depends on the previous one being successful for it to start and for websites with low throughput figures this approach might even work fine.

Every process step (reserve stock, take payment) could be and ACID transaction talking directly to a database. You would have very strong consistency and customers would indeed be happy. If you were to think in terms of services then each order step would be an atomic service, and your process control would simply call each service and get an OK (in which case it would call the next service in the workflow chain) or it would get an error (in which case it would perform some atomic rollback operations such as un-reserving the stock and return some conciliatory error message back to the customer).

Rollback

And here we have identified one of the quandaries of atomic services. What if a rollback fails? We have reserved(预定、保留) some stock successfully but, because the customer failed on payment, we have to un-reserve it successfully too. If the stock reserve/un-reserve service experiences an issue, we could end up with reserved stock that will never leave the warehouse, and we can't get into a wait-and-try-again loop because we have a customer waiting for an answer.

This scenario is interesting because we have an operation that's important to us, but not the customer. They care that we reserve stock for them, but not that we un-reserve something that they are never going to be receiving. If you think of the order process as a vector that must get from A (submitted basket) to B (happy, or at least informed, customer) then un-reserving stock is orthogonal to that process. And for scalability, orthogonal activities should be designed as asynchronous services - because they don't block and there's minimal latency (only long enough to acknowledge that the instruction has been received successfully).

Orthogonality(正交性

So there's an interesting idea. If we can remove operations from the order vector that are important to us but not the customer, perhaps we should ask ourselves long and hard about what really is important to the customer?

What about reserving stock? On the face of it, it seems logical to make this part of the critical path, but why? If we offline the entire stock control service what would be the experience? Well, we'd have to email the customer a few minutes later if we we're experiencing a stock level issue (once the asynchronous transaction had completed) and give them a chance to cancel the order, but we'd also have an opportunity to place a back order.

Not only do we get better scalability, we get an additional customer service and we've managed to decouple order processing workflow from the stock control service so if it's down we can still collect orders.

As an aside, much of the logic I am talking about here went into the development of the bespoke order management system that powered the Virgin Mobile UK website. I chose Gigaspaces as the operating platform for that system because it had another advantage that boosts scalability by a factor - grid technology that doesn't tie consumers and suppliers together.

Taking the pessimistic view that any legacy system we needed to talk to might suffer from sporadic availability, the design used a shared-memory Javaspace as a repository for order documents.

All a process step required was an order document in the appropriate state (i.e. needing a credit check) to be collected from the space and passed to the relevant legacy application. If the application was down the document remained in the space. The user was long gone from the process, having received a confirmation email on submission of the order. If a document sat too long in the space, an alert could be raised. If a document contained data that for some reason made it incompatible with a legacy application (e.g. non-existent post code entered erroneously) this could be fixed and the document put back in the space.

The point being that the "consumer" simply had to put a document of the right format into the space, having no idea of the implementation details or location of the "supplier". Moving things in and out of the space was atomic, as were the eventual writes to the database - thus, according to Brewers Theorem (在讲CAP的文章中http://pt.alibaba-inc.com/wp/dev_related_728/brewers-cap-theorem.html 看到该文的链接), we sacrificed immediate data consistency in return for improved availability of the money-making customer-satisfying processing engine and better partition-tolerance of those areas of the architecture that might not be as reliable as we need. This sacrifice is what also gives us scalability.

 

来自:http://www.julianbrowne.com/article/viewer/scalability

 

分享到:
评论

相关推荐

    The Art of Scalability

    "Scalability Mastery" Scalability是指系统、软件或应用程序能够满足增长和变化的需求,而不影响其性能和可靠性。Scalability是一个非常重要的概念,在现代软件开发和 IT 行业中扮演着关键角色。下面是从《The Art...

    Java Performance and Scalability

    Each optimization discusses techniques to improve the performance and scalability of your code. Every claim is substantiated with hard numbers and an experience-based evaluation. Java(TM) Performance...

    Scalability Rules: 50 Principles for Scaling Web Sites

    ### Scalability Rules: 50 Principles for Scaling Web Sites #### 书籍概述 《Scalability Rules: 50 Principles for Scaling Web Sites》是一本由Martin L. Abbott与Michael T. Fisher合著的专业书籍,旨在为...

    .NET Application Performace and Scalability

    Improving .NET Application Performance and Scalability provides an approach to engineering applications for performance and scalability.

    Scalability patterns

    标题与描述:“Scalability patterns”(可扩展性模式) 在IT领域,系统设计的核心目标之一就是确保其可扩展性,即系统能够处理不断增加的工作负载而不牺牲性能或稳定性。这通常涉及采用特定的设计模式和策略,以...

    Designing for Scalability with Erlang-OTP.pdf

    Designing for Scalability with Erlang-OTP.pdf Designing for Scalability with Erlang-OTP.pdf Designing for Scalability with Erlang-OTP.pdf

    Scalability Rules Principles for Scaling Web Sites(2nd) epub

    Scalability Rules Principles for Scaling Web Sites(2nd) 英文epub 第2版 本资源转载自网络,如有侵权,请联系上传者或csdn删除 本资源转载自网络,如有侵权,请联系上传者或csdn删除

    Java Performance and Scalability Volume 1

    Java Performance and Scalability Volume 1

    论文研究-Hybrid mapping service for the separation solutions of routing scalability.pdf

    根据文件提供的信息,这篇论文的标题为《Hybrid mapping service for the separation solutions of routing scalability》(《路由可扩展性分离方案的异构映射服务》),其内容主要围绕当前互联网路由表快速增长所...

    Advanced Computer Architecture - Parallelism, Scalability, and Programmability

    Advanced Computer Architecture - Parallelism, Scalability, and Programmability 高级计算机体系结构

    Tableau 服务器 scalability

    Tableau服务器的可扩展性(Scalability)是指该服务器系统在面对不断增长的用户负载和数据量时,依然能够维持性能和稳定性,且能够通过增加硬件资源来按比例提升服务能力的特性。在本白皮书《Tableau服务器可扩展性...

    Programming Scala- Scalability = Functional Programming + Objects, 2 edition

    注意是Programming Scala的第二版,而不是Programming in Scala的第二版,更注重于与Spark相关的知识!强烈推荐!Programming Scala- Scalability = Functional Programming + Objects, 2 edition

    5 Scalability Poisons and 3 Cloud Scalability Antidotes.pdf

    在当前的数字化转型和云原生应用的浪潮中,系统的可扩展性(Scalability)是架构设计中的一个核心问题。它关乎到系统能否在用户量、数据量等增长的情况下,仍能保持良好的性能和稳定性。然而,在追求可扩展性的过程...

    scalability

    ### 可扩展性(Scalability):理解分布式系统的核心概念 #### 一、引言 可扩展性是衡量一个系统或网络随着用户数量、数据量或其他资源需求的增长而能够保持稳定性能的能力。在信息技术领域,尤其是在分布式计算、...

    《架构即未来》英文原版,The Art of Scalability

    《架构即未来》是一本由Michael T. Fisher和Martin L. Abbott合著的书,它是关于构建能够平滑扩展以满足任何业务需求的产品和系统的权威指南。这本书详细介绍了两位经验丰富的软件、技术和商业执行官在管理世界上...

    the art of scalability

    《The Art of Scalability》是一本深入探讨可扩展性问题的书籍,它不仅仅关注于如何设计一个在高流量下不会崩溃的网站,而且更多地着眼于如何设计一个在业务增长时也能够稳步发展的公司架构。该书作者 Abbott 和 ...

    Pro Java Clustering and Scalability

    本书《Pro Java Clustering and Scalability》专注于介绍如何利用Java语言构建高性能的集群系统以及实现系统的动态可扩展性。在现代互联网应用中,集群和可扩展性是两个至关重要的概念,它们共同确保了系统能够处理...

Global site tag (gtag.js) - Google Analytics