本文转载自微信公众号「计算机世界」，作者Lee Atchison。转载本文请联系计算机世界公众号。
你可能正面临这样的处境：你拥有丰富的应用程序，还有大量使用这些应用程序的客户。除此之外，你还拥有大量的产品目录，商城也做得很大且功能丰富。一切看起来都很好。
但除了这些，你还要面对很多问题。
你的应用程序经常崩溃。当它出现问题时，虽然开发人员可以即时解决，并且他们修复站点的速度也很快，但这需要付出大量时间和精力。想象一下，如果这种宕机经常出现，一宕就是好几个小时，你会损失多少的生意?
你的开发人员也想解决这个问题，他们有很多想做的事情，比如他们一直想要实现一些很棒的新功能。但他们根本无法完成，因为修复错误和紧急救援消耗了他们太多的精力。
你想要雇用更多的人，但并没有足够的预算支持。而且，你还需要不断招聘新人以替换即将离职的人。例如：员工Judy去了一家更大的科技公司，员工Joe离开是因为他在深夜处理了太多的紧急情况，感到筋疲力尽。
技术问题不仅给你带来压力，也给你的团队带来压力。它让你看不到任何出路，把你和你的公司都困住了。
你掉进了一个许多软件公司和非软件公司IT部门都掉进过的陷阱。这些公司创建了可以处理所有事情的大型的整体式应用程序。但是这些应用程序因为变得太过庞大和复杂，以至于难以控制。没有人能完全了解应用程序中发生的所有事。
这时候问题出现了，这些应用程序需要不断地修复。你尝试添加新的功能或改进现有的功能，但这些更改牵一发而动全身，以至于你无法在短时间内完成这些尝试，而且就算它们完成了，也可能充满了错误。因此，你的开发速度变得很慢，而且越来越慢。这时你尝试增加更多的开发人员，但他们似乎并没有让事情进展得更快，而且新开发人员需要花费大量的时间去学习。
这时的你感觉就像被困在泥潭里。
其实困难是可以避免的。你不用全盘否定这些应用程序，而是根据公司需求重新构建他们。
不断增长的应用程序
你可以先从一个由一个人或一两个小型开发团队编写和管理的简单应用程序开始。这个应用程序如图 1 所示，简洁明了。
图1：一个简单但不断增长的应用程序
随着时间的推移，应用程序不断增长。因为应用程序的成功，导致流量急剧增加，所以你开始添加新的特性和功能，并雇用更多的开发人员来开发应用程序。很快，它就看起来像是图 2。
图2：一个复杂的、停滞不前的应用程序
现在，新的问题出现了。没人知道他们该负责应用程序的哪些部分。团队1做的改变会影响到团队3。因此，大家的压力都很大，生产力变得很低，而且错误会蔓延到整个应用程序中。于是你的站点开始出现故障，但这时候你可能还以为故障是随机产生的。当出现故障时，您的团队很难找出问题所在，因为没有人能够了解应用程序中发生的一切。这就是你遇到的典型困难。
你的独立开发团队并不是真正独立的，因为一个团队所做的改变会对其他团队的工作产生很大的影响。你不能处理独立的项目，因为所有的项目都是相互交织的。创新被扼杀了，你的业务也是如此。
微服务架构的价值
现在一起来看看图3。
图 3：基于微服务架构的应用程序
在微服务架构的应用程序里，每个服务都是独立于其他服务的。每项服务规模都较小，但量更大。每项服务之间都有明确的关联，而且也有着明确规范的业务逻辑。
更重要的是，每个服务都有单一的负责人，每项服务的所有方面都由一个开发团队负责。
干净的应用程序结构会使所有权和责任更清晰。
简而言之，你的应用程序得到了扩展。而且，这个扩展不是指它可以支持的客户数量变多了，而是它支持的独立开发人员、项目和计划更多了，因此可以支持和维护你不断增长的业务。
开发团队不会互相影响，因此工作效率变得更高。而且，因为低级问题变少，他们会更快乐，有可能在公司待得更久。
此外，你可以通过简单地再平衡所有权责任来增加开发团队的数量，从而增加开发人员的数量。越来越多的开发人员变得更有效率，并且你可以在所有重要的业务项目上取得更好的进展，从而使你的生意发展的更好。
如果出现问题，通过分析服务之间的交互，你可以更轻松地锁定问题的根源，以及哪个团队应该负责修复。此外，由于每个团队的职责范围变小，他们对自己负责的服务运作会更清楚，因此可以更快、更有效地解决问题。而且，因为他们更了解自己负责的领域，所以也不太可能将错误引入系统。
作者：Lee Atchison，云计算和应用程序现代化领域公认的专家。Lee在产品开发、架构、扩展和现代化应用方面拥有超过三十年的经验，曾在 Amazon、Amazon Web Services (AWS)、New Relic等现代应用行业工作过。Lee最近的一本书是《Architing for Scale(O'Reilly Media)》。
原文网址：
https://www.infoworld.com/article/3637016/why-you-should-use-a-microservice-architecture.html
