微服务：勇于在外部构建服务

　　如果你是一个应用程序架构师，你不可能错过我们大部队中出现的最新流行语：微服务。而如果你之前错过了，那么现在你已经找到了。

　　无论你是否熟悉微服务，我都想向你介绍对于微服务架构的一个重要澄清（我是这么认为的）：即简单的“ 内部架构”和更复杂的“ 外部架构”之间的区别。

　　首先，是一些等级设置…… 微服务架构承诺提供灵活性和可扩展性，来用于开发和部署基于服务的应用。但是，这个承诺是如何实现的呢？简而言之，就是采用一个架构，允许单独的服务被独立而动态地进行建立和部署；或采用一个包含DevOps实例的架构来实现。

　　需要向你的客户配置文件发送更新吗？嗯，这是“微”，所以它易于理解，开发人员可以只专注于功能。当准备妥当，你就可以测试和部署该服务了——无需将其与你应用程序的其余部分进行捆绑，无需等待释放窗口。当需求高峰发生在晚上时，是同一个服务创造瓶颈的吗？仅仅只需多部署几个（微）服务的实例，就可以实现向外扩展。

　　这一切听起来都很不错，对吧？这些都是微服务架构的各个方面，而以它为中心的讨论和引起的兴奋约活跃了12个月左右。 这些话题推动了相当多的热情。

　　微服务更加简单了，开发人员能够获得更多的生产力并且可以快速而精确地扩展系统，而不是在大的单片封装里工作。我这还没提到多语种语言编码和数据持久性的潜力呢。在我最近发表的研究“评估微服务架构的可扩展性应用程序交付”中，我把这称之为“内部架构”，它指的是微服务自己的实现架构。

　　但这不是故事的全部。为了走近上述（过于简单的）案例所显露的涅槃，你需要做一些工作：你有一个巨大的责任，就是坚持你的接口契约。你必须管理一个分布式系统的开发、部署和操作的复杂性。

　　为了简化服务，你已经从服务中去除了复杂性。而这个复杂性并没有消失，它带来了新的挑战，并放大了旧的挑战。你将会在以下情况中遇到这个“去除了的”复杂性：当你测试和部署微服务时，当你的微服务需要通信时，当你需要了解你开发环境的状况时，或者当你需要诊断这一分布的问题、和潜在的多语种语言时。

　　那种复杂性已经移除了，而我会说，它增加了。它现在存在于我称之为“外部架构”之中。外部架构为你提供所需要的平台能力，以帮助所有那些简单的小型微服务（以及他们的DevOps团队）一起工作，来兑现灵活性以及可扩展性开发和部署的承诺。正是应对这种复杂性使得SDLC规程和自动化成为了提供微服务架构必不可少的元素。

　　下面的图表是一个简化版本，在我的研究中发表过。它显示了内部和外部架构是如何联系的。微服务A到D是不同的服务（可能有不同的内部构架），它们每一个都有一个或多个实例部署和执行。

内部和外部架构

　　正如你可以看到的，你的架构的内部元素、内部组织处于你的服务实现之外，而在架构之内每个微服务封装了它的逻辑和数据持久性。如果你开始评估或采用微服务，你就需要考虑考虑这些外部架构能力以及每个人都为之兴奋的所有有趣的内部架构。

　　现在，我的观点是，对于外部架构而言最佳的切入点是aPaaS（应用程序平台即服务）平台或框架。但是，供应商们不会错过机会来进行“微服务-清洗”他们的工具和平台，以引起你的注意力。因为有些人会比其他人更适合微服务，所以我恳求你通过使用我们的搜索或做你自己的搜索来了解你所需要的功能，而不是等待供应商来告诉你他们认为你需要的（和应该支付的）是什么。

　　虽然微服务不是万能的，但是我能够看到微服务在改变我们构建、维护和操作应用程序方式等方面的潜力。当提供的微服务带有规程时，他们帮助应用程序变得更加可发展、更轻便、更具适应性。尤其是当组织着眼于将应用程序工作负载迁移到私有云或公共云平台的时候，情况更是如此。我鼓励你从Gartner和其他许多有关这一话题的资源中更多地了解微服务。

　　记住，交付一个成功的微服务架构需要勇气。

​

　　本文由寄云科技编译，未经授权谢绝转载。欢迎关注寄云科技订阅号（neuclouddy），这里有最新云服务行业资讯，更有与PaaS、运维相关的技术干货！