o.v*_*.v. 8 .net architecture cloud saas
从独立解决方案到软件即服务的有机增长过程是什么？明确地
可伸缩性不是开发结束时的"特性".^
所以我对所需的高级代码和架构更改感兴趣.
是否选择现有平台并使其超常化？
是否有人从裸骨云架构开始,然后迁移传统功能？
积极的技术升级(即网络表格> MVC)是否适合这个过程？
我被要求对当前的项目架构进行一些澄清.不需要太多细节,可以考虑一个.NET webforms应用程序,它可以插入一层业务逻辑并与多个第三方供应商集成.每当需要新的平台实例时(我在这里缺乏术语,我的意思是当新客户需要业务逻辑调整,与不同的第三方提供商集成,热门的新品牌等)时,现有代码是分支的,新的环境是建立.任何更改实际上都是非常低级的,无论它们是否直接发生在aspx文件,组件代码或db配置中.
这种情况似乎非常适合实施"适当的"SaaS模型,但我在构建性地为迁移过程做出贡献方面存在困难.要重新解释所提出的原始问题,这将是一个有效的策略:
对现有平台进行Overnormalize并使所有内容都可配置,有效地暂停此模拟可伸缩性,并且在重构体系结构之前不会引入新客户端.这个imho的缺点是继续依赖不是为可扩展性而构建的代码和结构(详情如下).
从头开始,任何被认为是(主题)解决方案的最佳架构,然后根据需要迁移传统功能.这允许几乎任何所需的技术升级,但在完成之前缺乏可见性,并且作为积极的变化,将被管理层视为固有的高风险.
我个人倾向于第二种选择,因为存在遗留代码的数量和缺乏足够的数据库规范化.同时,现有的解决方案是成熟的和功能性的(如果它没有被破坏,不要修复它),除了我上面列出的两种方法之外,还有很多方法可以扩展.
如果上面的上下文允许特定于场景的建议,我会接受它.然而,我仍然对更适合更广泛的观众的更一般的做法和指针开放.
关键是架构。方法就是分而治之。方法就是放松。
建筑物最重要的组成部分是其架构。墙壁和地板、窗户和天花板（即建筑本身的元素）塑造空间的方式。建筑师的目的不是设计墙壁。他将它们设计为实际工作的次要部分：设计由墙壁塑造的空间。我们建造建筑物不是为了有墙壁，而是为了拥有内部空间。
我们首先设计我们想要从软件中获得的功能。然后我们深入探讨使其成为可能的细节，即构建产品。我们使用的技术不是主要的，它们是墙壁，我们真正想要的是空间本身。
通过充分了解我们想要从正在构建的软件中获得什么，工程变得更加容易并且几乎是自动的过程。技术难题开始出现在易于理解的定义中，幸运的是，也有明显的解决方案。
衡量一个好的架构的一个非常重要的标准是它清楚地定义了解决方案的组件。当我们可以单独看到大图景的这些组成部分时，我们就可以将工作分成单独的部分。然后我们可以构建单独的东西来协同工作。
也许这个标题听起来像是我试图给文字带来一些幽默；但不，请不要误会我的意思。如果你有一个好的架构，你就可以放松，你的 Web 服务器、数据库服务器、工程师、客户、用户和世界其他地方也可以。如果情况并非如此，则意味着您应该回去处理您的架构。
嘿，我到底在这儿说什么？它有一些段落和三个标题，除了软件之外我没有使用任何软件术语。这种抽象的闲聊是为那些整天无所事事、懒洋洋地走来走去、说话、说话、说话的人准备的……我们是软件人，我们没有时间做这些。嘿，我，哈桑，长话短说……！
好的，我会尝试的；但首先，让我们放松一下……然后我们可以看一些真实的例子。
假设我们正在为专业人士和个人开发网络出版服务。每个客户都会有一个自己的网站，在我们的系统上运行。这些网站可以是访问者数量很少的普通个人网站，或者如果我们的业务幸运的话，我们的其他一些客户可以是像《纽约时报》这样的大型出版物。
我们需要解决两种可扩展性问题：随着我们开始拥有越来越多的客户、运行越来越多的网站，扩展我们的业务和系统。与第二个问题相比，这是一个相当简单的问题，第二个问题是随着越来越多的访问者、越来越多的数据、越来越多的应用程序在这些数据上运行而扩展单个网站。
我们可以将“如何缩放”的问题重写为“如何划分”，以便更清楚地看到解决方案。如果我们可以将某件事分成小部分，我们就可以通过添加更多资源来完成这些部分来扩展它，从而水平增长。
我们将拥有数据和可处理这些数据的应用程序。假设我们有一台数据库服务器和一台 Web 服务器，并尝试使其可扩展。
考虑我们将为我们的服务运行的网络服务器；如果我们不在这些机器上保存数据，它们将变成通用的、平等的组件，数据后端的小客户端，将这些数据与世界其他地方连接起来。通过保持我们的网络服务器轻量、愚蠢、空虚，我们可以轻松地让其中的许多服务器来处理越来越多的请求。
好吧，将网络服务器变成愚蠢的代理并不是最聪明的主意。我们需要做一些事情，运行一些应用程序。而且，因为在我们的架构中，Web 服务器是最容易扩展的，所以我们希望在这些 Web 服务器上做尽可能多的事情。我们将在下面的“更智能地划分”标题下继续解决这个难题。在此之前，我们先来看看我们目前拥有什么样的架构以及它的可扩展性如何。
We use load balancers to make many web servers run in parallel and also divide many web sites into groups using DNS (even before requests hit our system) to multiple load balancers. For example, a.com, b.com, c.com to load balancer 1, a-very-big-website.com to load balancer 2, ... Each group of a load balancer, a set of web servers and a database server makes a separate universe in our system. Now we can have millions of websites and grow our system by adding more of these separate universes without any limits. We can serve as many clients with as many web sites as our marketing department can bring. Our first problem is solved, already. What about running big big big websites?
Of course we cannot divide a single website into separate universes as we do with separate websites; but this does not mean we cannot divide anything at all. We will continue dividing and conquering. To do this, we need a closer look at the problems we solve.
What is a website? Web pages, supporting content like css and js files, multimedia content like image and video files, and data, lots of data. Thanks to CDNs and awesome storage services cloud computing systems provide, static files are not an important part of our problem anymore...
The real thing we do is rendering web pages. Above, we thought of our web servers as very light, generic interfaces to our database back-end. We did not solve how to run applications in our universes yet. Now it is time to do that.
Every request to our system will come to a site and be processed by an application running for that site. The very first thing our web servers will do is to decide which site a request belongs to. On our database server, we keep a table that matches hostnames to sites. With every new client website we have, we will add one or more domains to this table to match this site. With every request to our web servers, we will query the database server and decide which site to load. Good?
No, not good. It is awful. Why?
We have a small number of websites; but a very big number of requests. Number of websites on a universe changes much less frequently than other kinds of data like comments on blog sites. This table is updated maybe a few times a day on an established universe. Querying such a tiny (a few thousands records, tiny!) database for every request again and again all day is not smart. The smart way to do this is to keep copies of this table on web servers and update only when they are updated. How do we know when site list is updated? We can keep a row with a number as our table version number. With each update we can increase this number. Or we can keep a time stamp of last update. Web servers can check database server for this number and compare it to their local in-memory versions. If table is newer, we pull the data again overwriting the local in-memory copy. This way, we will have reduced thousands of queries to tiny numbers. Big numbers, small numbers...
At this point, what materials we use on our buildings started to matter. Which languages, what kind of platforms and database systems, etc. Now, they matter because they can make our architecture work better or worse. For example, for the update of table, our database server can have a mechanism to notify web servers about the update. This way, we will have gone even further and completely removed the unnecessary queries of domain-site table. So, if the systems we have chosen provide such mechanisms, it means these systems are good choices for our architecture.
Dividing things in a smart way happens automatically when we understand what we want from our software well. It is very difficult to scale database servers. Since we need data to be together. By increasing the number of web servers, we scale horizontally without any limits; but for database server, this is not applicable. Database server has to keep access to data and machines has limits that we cannot scale in an efficient way.
Every database system provides ways for scaling like sharding or shared-nothing architecture. There can be a time that you have to use these; but as I see on forums, blogs, and other places people share their experiences, IMHO, people use these too aggressively and wrongly. They let their databases grow bigger and bigger then "hey it is time to scale, let's add some shards." 99% of all these applications are blind-running. People throw their problems to software and expect them to be solved like magic. Unfortunately, they realize very soon that there is no magic.
We should keep ourselves from blind-running solutions by watching our numbers: big numbers, small numbers. Also by understanding our system's inner workings and solving problems via architecture instead of heavy use of materials.
Here is an architectural solution: Architected Solution (by Calatrava).
Here are other solutions that depend on materials instead of good architecture: [Blind-run Solution 1], [Blind-run Solution 2]
Judge the difference yourself.
How can we scale a database server? Instead of blindly dividing tables in the middle, we can rethink about our data. Can we separate user account information from site templates? Of course, why not? Can we take keep different database servers for old data and fresh ones? A little more difficult, especially considering search facilities; but why not?
Divide smartly, not blindly! I accept there will be times that you cannot divide it anymore; but come on, how many of us are working for Google or Facebook?
-- Hey man, we have a very large data set and when we run...
-- Shush. First, go back and check your data set. Does it really have to be a large data set?
Most of the time, no, it does not. We just don't want to admit it...
Rebuilding everything from scratch takes time that many businesses cannot afford. The better way is to architect our current system without rewriting every component; but instead, separating and redefining them as components. This is mostly analysis followed by little changes. Every function call on a system can easily be a point of division. We can just cut the system from that point into two pieces.
A happy look on your current system for just a few hours will show you a lot of ideas on how to divide those pieces. Once you divided them, it is very easy to re-architect everything and then re-build your new system piece by piece. If I have a building and I need a bigger building on the same land, to build the new building without moving all the people already living there is a very difficult job; but not impossible. When it comes to software instead of buildings, it is much easier. So?
It is software. It is soft. You can copy your data, make tests on it, delete everything, copy a million more times. Once your architecture is designed well, your mistakes never cause catastrophic events. It is very difficult to turn a 6-seat dinner table into one that can serve 60 guests; but software is ... software and we can easily do such things. Relax.
-- The question above touches such an area that is impossible to cover in just a few paragraphs. Based on this part from the question: "However I'm still open to more general do-s and dont-s and pointers suitable for a wider audience." I tried to mention things in a general format without diving into details. Although I tried to give a few tiny examples of practical applications of my principles, I know I have left many open ends in this short text. I appreciate any criticism and questions in comments.
| 归档时间： |
|
| 查看次数： |
1227 次 |
| 最近记录： |
