系统技术方案 系统构架

by Ayelet Sachto

通过Ayelet Sachto

架构系统时要记住的6件事 (6 Things to keep in mind when architecting a system)

Architecture may sound like a “scary ” or overwhelming subject, but actually, applying logic and approaching the problem methodologically simplifies the process drastically.

体系结构听起来可能像是“恐怖”或压倒性的话题，但实际上，应用逻辑并以方法论的方式解决问题可以极大地简化流程。

When you architect a system, service, or feature, you actually design a solution to a problem in a specific context. The solution should answer a real need and solve the problem at hand.

当您设计系统，服务或功能时，实际上是在特定上下文中设计问题的解决方案 。 解决方案应满足实际需求并解决眼前的问题。

Throughout the text, I’ll be using solution in order to emphasize that the systems, services, and features we build are part of a bigger flow.

在整篇文章中，我将使用解决方案来强调我们构建的系统，服务和功能是更大流程的一部分。

When designing a solution think about the entire environment flow you affect.

设计解决方案时，请考虑您所影响的整个环境流程。

• Think about what happens before the data reaches your code
  想想数据到达代码之前会发生什么
• What triggers your feature or service
  是什么触发了您的功能或服务
• Who sends it?
  谁寄的？
• Is it something automatic?
  它是自动的吗？
• Is it a user?
  是用户吗？

This will also help you think about tests and edge cases you want to address, what happens after, who would use it and how.

这也将帮助您考虑要解决的测试和极端情况，之后发生的事情，谁将使用它以及如何使用。

1.了解问题 (1.Understand the problem)

Start from understating the problem at hand and understand your boundaries. Don’t optimize for an unknown future, focus on the current situation and most importantly, don’t make assumptions. Don’t limit yourself by requirements that are not there.

从轻描淡写眼前的问题开始，了解您的界限。 不要针对未知的未来进行优化，而要关注当前情况，最重要的是， 不要做任何假设。 不要受到不存在的要求的限制。

Make sure you have all the information you need to understand the problem, don’t be afraid to do research, Google is your friend ;)

确保您拥有了解问题所需的所有信息，不要害怕进行研究，Google是您的朋友;)

2.了解您的界限并设定优先级 (2. Understand your boundaries and set priorities)

Solution architecture is always a trade-off between concerns, such as resilience, security, data integrity, throughput, scalability, performance and of course cost.

解决方案体系结构始终是折衷之间的权衡，例如弹性，安全性，数据完整性，吞吐量，可伸缩性，性能以及成本。

Think about value vs friction

考虑价值与摩擦

Understand your constraints. What are your must-haves. If you have a product team, work with them in order to understand the business need, impact and SLA’s. This will help you understand your considerations and limitations better.

了解您的约束。 您必须具备什么。 如果您有产品团队，请与他们合作，以了解业务需求，影响和SLA。 这将帮助您更好地了解您的注意事项和限制。

Use data to make priorities, avoid assumptions when possible and be data-driven.

使用数据 确定优先级 ，在可能的情况下避免假设，并以数据为驱动力。

• How many users?
  有多少用户？
• Number of requests?
  请求数量？
• Size of requests?
  请求大小？

Test your service in order to estimate the resources that are needed.

测试您的服务以估计所需的资源。

Make sure you address the maximum rate you want to support and not only the average (look at percentage vs average).

确保您解决了要支持的最大比率，而不仅仅是平均值(查看百分比与平均值)。

Think about solving the problem and not just how to solve it. First think about the solution and only after that think about the implementation. When you free yourself from the expectation of how the solution should look like, you understand that a solution can be provided in many forms. It can be a system, service, feature, process or even documentation.

想想解决问题，而不仅仅是如何解决这个问题。 首先考虑解决方案，然后再考虑实现。 当您从的解决方案应该如何看起来像期望中解放出来，你明白，一个解决方案能够以多种形式来提供。 它可以是系统，服务，功能，过程甚至文档。

3.问为什么？ (3. Ask WHY?)

Challenging people and even yourself can be frustrating sometimes. But asking why can help you solve the real problem, understand the mandatory requirements and your boundaries, and can help you avoid mistakes and understand the motivation from the business side.

挑战性的人甚至您自己有时都会感到沮丧。 但是问为什么可以帮助您解决真正的问题，了解强制性要求和边界，并可以帮助您避免错误并从业务方面了解动机。

• Why is it a real pain?
  为什么是真正的痛苦？
• Why should it be done like this?
  为什么要这样做？
• Why it works like this today?
  为什么今天这样工作？

Challenge yourself and ask questions. It will help make better decisions and better solutions.

挑战自己，问问题。 这将有助于做出更好的决策和更好的解决方案。

4.您的解决方案不是在真空中 (4. Your solution is not in a vacuum)

Context is important. A startup of 4 people that needs to provide MVP and is limited by funds will and should solve a problem differently than a team in a big organization that needs to create a sustainable product that will need to be maintained by several teams.

上下文很重要。 与需要提供MVP并受资金限制的4人创业公司相比，解决这个问题的方式应该不同于大型组织中需要创建可持续产品(需要由多个团队维护)的团队。

Going back to my first statement, after you understand the problem think about the context.

回到我的第一句话，理解问题后，考虑一下上下文。

• What are the tools you have at your disposal?
  您可以使用哪些工具？
• Are you part of a big organization?
  您是大型组织的成员吗？
• Are there any limitations such as time or money?
  有时间或金钱等限制吗？
• Who will maintain the solution?
  谁来维护解决方案？

Think about what is right for your situation, define what production ready means to you, and whether it should be highly available (HA). Think about the ROI. Should you address Edge cases?

考虑什么适合您的情况，定义准备生产对您意味着什么 ，以及它是否应具有很高的可用性(HA)。 考虑一下投资回报率 。 您应该解决边缘案例吗？

• How would you design a solution that will return values from a database?
  您将如何设计一个将从数据库返回值的解决方案？
• And what if I told you that it would be used only once a week until the end of the year. Would it change your answer? Would it affect the design?
  而且，如果我告诉您，直到年底将仅每周使用一次，该怎么办。 它会改变您的答案吗？ 会影响设计吗？
• If you have 1 day to build a solution would it be the same as if you had a month?
  如果您有1天的时间来构建解决方案，那将与您有一个月的时间一样？

Think about growth. For different solutions and different companies, growth means different things. It can be from a scale perspective, such as supporting the growth of additional users. It can also be from a functionality perspective, where your solution should be flexible to enable other developers to add /modify functionality with ease.

考虑增长 。 对于不同的解决方案和不同的公司，增长意味着不同的事情。 它可以从规模角度来看，例如支持其他用户的增长。 从功能的角度来看，它也可以是灵活的 ，您的解决方案应具有灵活性，以使其他开发人员可以轻松添加/修改功能。

5.费用 (5. Cost)

As engineers and developers, we sometimes do not stop to think about the cost of our solutions and services. From my experience it is mostly due to lack of awareness and not willingness.

作为工程师和开发人员，我们有时不停地思考我们的解决方案和服务的成本。 根据我的经验，这主要是由于缺乏意识和不愿意。

When we are at university, we are “pumped” with performance and complexity concerns, and taught to think about the efficiency of the solution. But when designing a product that will be used, we need to also think about efficiency with regards to cost. You can build an amazing stable and reliable service that provides value, but if its ROI is not high or if your company won’t be able to afford the cost, it will be axed in favor of other alternatives.

当我们上大学时，我们会被性能和复杂性问题“困扰”，并被教会去思考解决方案的效率。 但是，在设计将要使用的产品时，我们还需要考虑成本方面的效率。 您可以构建出色的稳定，可靠的服务来提供价值，但是如果投资回报率不高，或者如果您的公司无法负担得起成本，那么它将被其他替代方案所取代。

Remember, performance and infrastructure are not free.

请记住，性能和基础架构不是免费的。

6.生产部署仅仅是开始 (6. Production deployment is only the beginning)

An important concept that sometimes is neglected is maintenance. Is our system or service stable and easy to maintain, debug, troubleshoot and fix?

维护有时是一个有时被忽略的重要概念。 我们的系统或服务是否稳定且易于维护，调试，故障排除和修复？

Production deployment is only the beginning of our solution. Make sure it can be easily maintained, make sure it is production ready and can serve real traffic and users. When developing your solution, think about end to end monitoring, focusing on application monitoring vs. utilization, and make sure to add logging and documentation.

生产部署仅仅是我们解决方案的开始。 确保可以轻松维护它，确保已准备好生产并且可以为实际流量和用户提供服务。 在开发解决方案时，请考虑端到端监控，着重于应用程序监控与利用率，并确保添加日志记录和文档。

When designing your solution, think about a simple and easy to maintain design, as much as the requirements allow for it of course.

设计解决方案时，请考虑一个简单且易于维护的设计，当然要满足需求。

As developers, we are sometimes drawn to new “flashy” and trendy technologies. Stop to think whether this technology is mature enough. Could it be maintained in production? Could a different stack be more efficient or offer fewer risks?

作为开发人员，有时我们会被吸引到新的“时髦”技术。 停止思考这项技术是否足够成熟。 可以在生产中进行维护吗？ 不同的堆栈能提高效率还是减少风险？

结语 (Wrapping up)

To recap, if you want to architect the best solution EVER, start from understanding the problem and your limitations, and know the context of the solution you are trying to design for.

总结一下，如果您想构建有史以来最好的解决方案，请先了解问题和局限性，然后了解要设计的解决方案的上下文。

Then think about what happens with your solution after it’s up.

然后考虑解决方案启动后会发生什么。

Unless you have unlimited funds (which is never the case), think about your solution’s cost and make sure that it maintainable.

除非您有无限的资金(永远不会这样)，否则请考虑解决方案的成本并确保其可维护。

If you liked what you read, be sure to ? it below!

如果您喜欢阅读的内容，请务必阅读？ 在下面！

Let me know in the comments ❤ if you like more architecture posts and/or would like me to deep dive about each of the points above.

在评论❤中让我知道，如果您喜欢更多的建筑文章和/或希望我深入探讨上述各个方面。

翻译自: https://www.freecodecamp.org/news/what-to-keep-in-mind-when-architecting-a-system-912ec5c6f79/

系统技术方案 系统构架