点击查看目录
本文为翻译文章，点击查看原文。
在做项目的云原生改造时我们可以采用微服务架构。DevOps 和自动化构建两方面的成功经验对微服务的实践很有帮助。经过一段时间的实践，你可能会有将微服务架构推广到其他部门的想法。而你担心微服务本身的复杂性和分布式系统的高维护成本会让其他部门难以接受它。可能在我们想方设法解决微服务带来的问题时，总会有些人觉得这样做毫无意义。因为现在技术发展如此之快，总会出现更好的技术方案，你能保证自己在微服务领域所做的工作最后没有白费吗？
我认为不会白费！
现在“serverless”和“functions-as-a-service”（FAAS）还处于早期的炒作阶段。有些人觉得 serverless 就是下一代的微服务，所以我们应该跳过当前的微服务模式而直接采用 serverless。其实这种说法是有点夸大其词。作为架构师或开发者，我们通过学习新技术来提升自身能力让自己变得更"值钱"并没有错。但我们也要以务实态度来判断是否应该采用新技术。虽然持续跟进最新技术是我们作为架构师的职责所在，但掌握在之前的产品和 IT 部门引用新技术的时机也很重要。我们可以通过下面的模块来理解微服务架构和 serverless，从而让它们可以更好的融入我们的技术栈。
首先，我们需要知道为什么我们需要微服务。选用微服务架构的主要原因就是避免项目的体量阻碍产品的迭代，所有微服务其他的优势都是基于这点。更快的迭代速度意味着可以更快的为客户交付新功能/修改，从而更快的验证这些改动能够带来的效果。我们需要快速的知道自己所做的努力是否能够带来好的效果，如果不能就要马上调整方向。快速迭代就是微服务架构的核心优势。
对于大多数的团队而言，至少有一部分应用能从微服务的迭代过程中获益。因此作为架构师或开发者，我们不要因为采用微服务有门槛就对其失去信心。实践微服务的重要步骤就是确定和测量改进指标。改进指标一般可以为每天迭代应用的次数、保证迭代应用稳定性的方法等。
另一方面，不是所有的应用都需要用这种松散而复杂的方式来保证服务的迭代速度。如果只想简单做个应用来验证自己创意的商业价值，那你完全可以选择更加适合的架构。这时采用 MVP 测试（最小可行性测试）就是个很好的方案。如果你因为商业价值很低而打算放弃的话，那也只是放弃了一个 MVP 应用。你可以非常快的迭代它并从潜在的用户中获得反馈。在这种情况下，你可能需要根据反馈反复修改 API、功能边界、组件等。所以过早就将组件功能做成分布式的服务也会拖慢产品的发布速度。你想修改分布式组件和它的 api 就必须在各个团队间进行协调。
上述观点能够反映出微服务架构和单体架构适用不同的场景。而事实上并没有所谓"一招鲜吃遍天“的方案。当我们在微服务架构和单体架构之间纠结时，还需要考虑到所需服务是否已经存在以及它提供服务的方式（第三方服务/公司内部服务）。我们完全可以充分利用当前已有服务来构建我们的应用，不必重新购买硬件、安装和修补操作系统，以及优化服务从而达到最高吞吐量，而这也正是云及其服务存在的意义。云供应商和他们的合作伙伴能提供数据库、消息队列、缓存、CDN 和其他更高级的功能：例如语言翻译、地图/地理空间地图、天气等。我们可以组合各种按量付费的服务来构建自己的应用。如果在使用某个服务的时候无需关心安装、参数和容量等问题，其实我们就已经在采用 serverless 架构了。serverless 架构的特点就是可以重用已经存在的 service，而无需关心运行服务需要消耗些什么。
函数即服务和 serverless 具有某种联系，因为它利用了缩小到单个应用程序函数的范围的计算模型，而这有助于将各种服务组合在一起构建应用。在这种模型下，功能按需分解，你只需为使用的功能付费。它特别适合对我们使用的服务进行按需计费和按量付费。这样一来我们能够构建弹性应用，而不需要考虑复杂的技术问题。将这些复杂的技术问题外包给别人可以让你更专注于为客户提供商业价值。
但是将这部分能力外包不总是可行的。如果选择云服务，我们就丧失了对程序运行时、具体功能、bug 修复和接受监管的控制力。这也是需要考虑的一部分。
serverless 不一定是完整的“公有云或无云”方案。如果以单个组织的角度来看，“serverless"可能只是代表整个体系的其他部分。例如：零售业务可以为组织内部其他服务或第三方提供“购买“服务以支持诸如分析、推荐以及其他使用“购买”服务的应用。利用定义良好的 API 和订阅并消费 API 的工作负载，你可以在自己的基础设施为微服务应用或单体应用提供 serverless 能力。在很多时候这其实就是服务向 SOA 架构进化的方向。但它们之间最大的不同就是在你将组织看作一个整体时，自己给自己的其他部分提供服务并不算 serverless。因为此时还是需要自己手动的去安装、管理和更新应用。
最终采用哪种方案其实取决于很多因素，例如：业务、商业目标、软件部门对该技术的熟练度和历史遗留问题等。如果你觉得应该采用微服务架构，那就不要因为其他新技术而分心。我们可以持续跟进最新技术，从而保证适时的采用它们。总的来讲，不管是微服务架构、单体架构还是 serverless 架构，它们都有自己的应用场景。
