世界上大多数的应用程序，可能有90%，都是由单体结构（monolithic）完美地提供服务的。
Randy Shoup在Summit 2018年峰会上宣布，为了避免过度设计，我们应该从一个简单的架构开始，并根据需要进行演进。在他最近发表的演讲中，他描述了自己与在一些公司的项目经历，这些公司起初规模很小，后来发展成为大型全球性互联网公司，它们的架构在那段时间是如何演变的，以及他从IT的角度对新公司或新产品的建议。
Shoup曾在eBay、谷歌和Stitch Fix工作过，目前是WeWork技术副总裁。他的第一个例子是eBay，它于1995年作为一个为期三天的周末项目启动，目的不是验证商业概念(PoC)，而是为了看看是否有可能在网上做一些有趣的事情。今天，它已经是第五次完全重写基础架构，Shoup将该公司描述为一个多语言的微服务集合，并补充说Twitter和亚马逊都经历了类似的演变。
从某种形式的单体结构（Monolith）开始，以一组微服务结束，这对于Shoup来说是大公司的一种常见模式，并注意到这一模式中有两个部分：
Shoup所提到的公司都非常庞大，在他们的规模下工作的架构对大多数公司来说是完全不合适的。大多数应用程序都是由单体结构提供服务的，Shoup在构建新应用程序或系统时的建议是，从简单的开始，并根据需要改进整个系统的体系结构。
对于大多数公司和产品来说，一个常见的进展曲线包括：
根本不应该有任何花哨的架构——这个时点最关键的是原型。为了避免过度设计，我们应该不断地问自己：“最想要解决的是什么问题？”这一阶段的目标是尽可能快地探索解决方案，并以最小的成本来实现:
在这一阶段，如果可能的话，不需要引入任何不必要的技术，例如使用谷歌广告来查看是否有人点击它，直接使用纸和笔或Excel电子表格就能解决大部分问题。
在构思及开始阶段时，目标是满足客户的短期需求，并尽可能地降低成本。通常这个阶段可以由一个4-6人组成的小团队来进行快速迭代，项目时间一般很短，大概3-4个月，快速的探索解决方案。此时，通常很难预见将来要构建什么特性，因此只需要很少的架构，就足以让我们快速前进。在这阶段考虑的不是伸缩性的，而是应该使用简单和熟悉的技术，并且绝对是单体架构——比如，一个应用程序和一个数据库。而且基础设施建议使用开发代价最小的，不要自己去构建；相反，可以使用平台即服务(PaaS)或类似的技术服务。
在这一点上使用单体架构的优势包括:
除了缺乏可伸缩性和单点故障外，单体架构的一个主要缺点是在模块化方面不给力。但是在这个阶段，这些都不是关注的重点。尽管如此，有意识地在单体架构中使用组件或模块来遵守模块化原则，为了后续的扩展提前做准备是值得的，这将简化未来的服务拆分与系统重构。
什么时候需要重建这个庞然大物，以下是一些可供参考的征兆:
当我们进入扩展阶段时，目标是领先于快速增长的业务，并保持应用程序正常运行。在组织环境中，这阶段通常会增加团队人员的数量，并在更长的时间范围内工作，通常还需要引入可重复的标准化流程（例如，开发流程、发布流程）。
在技术方面，扩展阶段通常意味着向可扩展的技术迁移。现在可以从整体上拆分单体服务，尝试减少单个数据库上的负载，例如创建一些数据的只读副本实现读写分离。按业务拆分服务（例如，支付和计费服务），并引入中间件、消息服务等。
这个阶段通常也是考虑是否应该将单体服务迁移到微服务的时候。此外还必须考虑存储，使用单点主存储是否仍然是存储数据的正确方法。在QCon纽约2017大会上，Shoup展示了如何将单体应用程序增量迁移到不同领域的微服务和多个独立存储机制。
在《可伸缩性的艺术》一书中，描述了一个三维可伸缩性模型（AKF Scale Cube），其中三个轴表示不同类型的可伸缩性:
如果达到这个阶段就是成功的标志。我们的目标是维持功能稳定，并且使用更少的资源以及更少的团队。这个阶段可能会有更长的时间跨度，比如2-5年。
重新构建一个系统是成功的标志，而不是失败的标志。重构是由于业务发展的好，业务体量的增长对现有技术有了新的要求，而绝不是为了重构而重构。
今天就先讲到这里。
如果看了这篇文章之后有所收获，欢迎收藏转发。
如果你有自己的见解，也欢迎在下方评论。
总之，你可以关注一下我，我会有许多干货分享。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
