当你真的搞砸了分布式系统的设计时该怎么办？
相关问题： 分解集中式数据库最有效的方法是什么？
我将尝试使这个问题变得相当普遍，以便使其他人受益。
大约 3 年前，我实施了集成的 CRM 和网站。因为我想给客户留下深刻的印象，所以我实现了我能想到的最便宜的架构，即将中央数据库和网站托管在 Web 服务器上。我创建了一个桌面应用程序，它通过 Web 服务与 Web 服务器进行通信（该应用程序从他们的主办公室运行）。
事后看来，这是相当愚蠢的，因为现在公司已经发展壮大，他们的互联网连接每个月变得越来越慢。现在，由于速度问题，桌面软件经常超时，客户有 3 个选择：
- 购买更快的互联网连接。
- 将数据库（和网站）移至内部服务器。
- 重新设计架构，使 CRM 和 Web 数据库分开。
第一个选择是“最简单的”，但从长远来看肯定不是最便宜的。第二个选项；如果我们将网站转移到内部托管，客户必须解决诸如互联网连接过载/不良/离线、断电等问题。最后的选择是；客户不愿意支付一大笔现金让我重新设计和重新编码架构，而我负担不起免费这样做（我需要吃饭）。
当你把分布式系统的设计搞砸了，以至于所有选项都不起作用时，有什么方法可以恢复吗？或者是减少损失并从错误中吸取教训？我感到很糟糕，因为这个问题没有快速解决办法。
Related question: What is the most efficient way to break up a centralised database?
I'm going to try and make this question fairly general so it will benefit others.
About 3 years ago, I implemented an integrated CRM and website. Because I wanted to impress the customer, I implemented the cheapest architecture I could think of, which was to host the central database and website on the web server. I created a desktop application which communicates with the web server via a web service (this application runs from their main office).
In hindsight this was rather foolish, as now that the company has grown, their internet connection becomes slower and slower each month. Now, because of the speed issues, the desktop software times out on a regular basis, the customer is left with 3 options:
- Purchase a faster internet connection.
- Move the database (and website) to an in-house server.
- Re-design the architecture so that the CRM and web databases are separate.
The first option is the "easiest", but certainly not the cheapest long term. Second option; if we move the website to in-house hosting, the client has to combat issues like overloaded/poor/offline internet connection, loss of power, etc. And the final option; the client is loathed to pay a whole whack of cash for me to re-design and re-code the architecture, and I can't afford to do this for free (I need to eat).
Is there any way to recover from when you've screwed up the design of a distributed system so bad, that none of the options work? Or is it a case of cutting your losses and just learning from the mistake? I feel terrible that there's no quick fix for this problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
你没有搞砸。客户想要最便宜的选择，你给了他们，这就是他们推迟的成本。我希望你没有向你的客户承担责任。如果他们责怪你，这是他们花钱买雪佛兰却想要一辆奔驰的典型案例。
据此：
您的客户需要就做什么做出业务决策。您的工作是以尽可能诚实和专业的方式向他们解释每个选择的后果，并将选择权留给他们。
请记住，您没有搞砸！您为他们提供了一个可以满足他们多年需求的解决方案，他们对此很满意，直到他们超出了系统的设计基础。如果他们不想在三年后再次维持系统的可扩展性，那么他们现在就必须愿意为此付费。软件并不神奇。
You didn't screw up. The customer wanted the cheapest option, you gave it to them, this is the cost that they put off. I hope you haven't assumed blame with your customer. If they're blaming you, it's a classic case of them paying for a Chevy while wanting a Mercedes.
Pursuant to that:
Your customer needs to make a business decision about what to do. Your job is to explain to them the consequences of each of the choices in as honest and professional a way as possible and leave the choice up to them.
Just remember, you didn't screw up! You provided for them a solution that served their needs for years, and they were happy with it until they exceeded the system's design basis. If they don't want to have to maintain the system's scalability again three years from now, they're going to have to be willing to pay for it now. Software isn't magic.
我不会称其为搞砸了，除非：
搞砸了就是过度设计一个高度复杂的系统，其成本超过了当时的规模需求。
事实上，最好只投资企业当前可以利用的金额，并在需要时利用增长为可扩展性的进一步投资提供资金。这是简单的风险管理。
当然，随着业务随着时间的推移而增长，大概是在您的软件的帮助下，他们也为下一个级别预留了一些东西。他们应该感谢您帮助他们的业务发展超出预期，并向您投入资金，以便您可以帮助他们实现新的增长水平。
所有这三个选择都可能不错。哪一个最好取决于成本效益分析、投资回报率等。这部分是技术决策，但主要是业务决策。
恭喜您帮助建立了一个不断发展的业务至今，并走向未来。
I wouldn't call it a screw up unless:
A screw up would have been to over-engineer a highly complex system costing more than what the scale at the time demanded.
In fact it is good practice to only invest as much as can currently be leveraged by the business, using growth to fund further investment in scalability, should it be required. It is simple risk management.
Surely as the business has grown over time, presumably with the help of your software, they have also set aside something for the next level up. They should be thanking you for helping grow their business beyond expectations, and throwing money at you so you can help them carry through to the next level of growth.
All of those three options could be good. Which one is the best depends on cost benefits analysis, ROI etc. It is partially a technical decision but mostly a business one.
Congratulations on helping build a growing business up til now, and on to the future.
您确定超时的原因是互联网连接，而不是 Web 服务/CRM 系统中的某些性能问题？通过超时，我假设你的意思是大约30秒，在这种情况下：
排序：您目前拥有的架构（基本上）对我来说似乎很好，因为（除了性能问题）公司对 CRM 系统的访问应该与公众对系统的访问相当 - 只要您的客户有合理的响应时间，公司也应该如此。
Are you sure that the cause of the timeouts is the internet connection, and not some performance issues in the web service / CRM system? By timeout I'm going to assume you mean something like ~30 seconds, in which case:
In sort: the architecture that you currently have seems (fundamentally) fine to me, on the basis that (performance problems aside) access for the company to the CRM system should be comparable to accesss for the public to the system - as long as your customers have reasonable response times, so should the company.
在本地网络上安装数据库的副本。然后让客户端软件与本地副本进行通信，并让数据库软件进行本地数据库服务器与Web服务器上的数据库之间的同步。这取决于您使用的数据库，但其中一些数据库具有实现该功能的工具。在 MSSQL 中，这称为复制。
Install a copy of the database on the local network. Then let the client software communicate with the local copy and let the database software do the synchronization between the local database server and the database on the webserver. It depends on which database you use, but some of them have tools to make that work. In MSSQL it is called replication.
首先，您确实需要丢弃多少代码？您的桌面客户端使用什么语言？ .NET 的东西，你也许能够挽救系统逻辑的大部分，只需要重做 UI 和一些连接。
我的想法是，1 和 2 是不可能的，而 1 可能是一个好主意，但它不能解决真正的问题。作为工程师，我们应该尽可能尝试构建不依赖于客户的解决方案。 2 让他们进入一些他们不擅长的领域，最好将托管保留在其他地方。
另外，既然你提到了网络服务，那么你真的失去了用户界面吗？您始终可以重用 Web 服务器接口的 Web 服务。
最后，您可以考虑使用一个框架来帮助提供一个简单的基于 Web 的 CRUD，然后从那里开始扩展。
First things first how much of the code do you really have to throw away? What language did you use for the Desktop client? Something .NET and you may be able to salvage a good chuck of the logic of the system and only need to redo the UI and some of the connections.
My thoughts are that 1 and 2 are out of the question, while 1 might be a good idea it doesn't solve the real problem. And we as engineers should try and build solutions not dependent on the client when ever possible. And 2 makes them get into something they aren't experts at and it is better to keep the hosting else where.
Also since you mention a web service is all you are really losing the UI? You can alway reuse the webservices for the web server interface.
Lastly you could look at using a framework to help provide a simple web based CRUD to start and then expand from there.
您确定连接已饱和吗？您可能会遇到各种网络、I/O 和数据库问题...除非您已经这样做了，否则请使用wireshark 来分析流量；测量吞吐量并与我们分享结果。
Are you sure the connection is saturated? You could be hitting all sorts of network, I/O and database problems... Unless you've already done so, use wireshark to analyze the traffic; measure the throughput and share the results with us.