自从2011年微服务这个词被杜撰出来，它就在前瞻的应用开发机构中引起轩然大波。过了短短几年，微服务即成为主流，根据Nginix最近的调查，36%受调查的企业当前正在使用微服务，另外26%还在研究阶段。但到底什么是微服务架构呢?它适合你的机构文化、技能和需要吗?
一起来看看你应该在下一个应用开发项目使用微服务的七个理由，还有五个你成功的道路上必须扫除的障碍。
用微服务的理由
微服务是面向服务的体系架构(SOA)的一个变体，它是这样一个架构样式，在这里应用程序被分解为多个宽松地耦合的服务。有了细粒度的服务和轻量级的协议，微服务可以提供增强的模块、使应用更容易开发、测试、部署、还有更重要的是变更和维护。
当中心化的、多级的架构被用来在单个代码库上创建整个应用时，毫无疑问你的机构仍然受制于单体时期开发的应用。在台式机主宰IT时期客户服务模式是一个极好的选择。但是由于移动设备和云的兴起，后台数据必须对一系列的设备可用，而单体架构不再让你轻松了，因为不管什么时候做出更改，系统都必须被更新，每次你要添加功能或调整到新环境时，它都为新错误创造了可能性。更糟糕的是，由于一切都受到单个代码库的束缚，你不能扩展某一个功能或服务，你必须扩展整个应用，这导致极其高昂的成本。
有了微服务，你的代码被分解为以独立进程运行的独立服务。在独立的、通信的服务的编制下，来自一个服务的输出被用作另一个服务的输入。微服务对那些对自己的应用所能支持的一些列设备没有预设概念的企业尤其有用。由于微服务是设备和平台无关的，它使企业能开发这样的应用，这种应用能提供跨越多个平台的持续的用户体验，横跨网页、手机、物联网、可穿戴设备和智能手环等环境。网飞(Netflix)、贝宝、亚马逊、易趣和推特只是其中几家使用微服务的企业。
例如沃尔玛加拿大，它于2012年将它的软件架构重构成微服务。该公司在当时一直不具备处理每分钟600万页面的能力，几乎在一夜之间实现了转化率大幅增长的结果。停机时间也被最小化了，公司可以用较廉价的x86服务器代替昂贵的商用硬件，结果是总体成本节省了20%~50%。
即便你的机构没有沃尔玛和亚马逊的体量，微服务依然可以提供巨大的价值。下面是转向微服务后你的机构能得到的其中一些好处。
增强的适应性
有了微服务，你的整个应用都去中心化了，不像单体架构，代码里的一个故障会影响到多个服务和功能，用微服务的话故障的影响很小。甚至当几个系统都停机维护时，你的用户也注意不到。
改善的扩展性
扩展性是微服务的关键方面。因为每一个服务都是一个独立的组件，你可以扩展一个功能的规模而不影响整个应用。业务关键型服务可以被部署在多台服务器上，在不影响其它服务的性能的情况下增强可用性和性能。
用正确的工具做正确的任务
有了微服务，你就不必受制于单个供应商。你可以灵活地用正确的工具做正确的任务。每个服务都可以用它自己的语言、框架或辅助服务而同时可以和你的应用里的其它服务通信。
更快的上市时间
因为微服务是在宽松的耦合服务上工作的，你不必重写整个代码库来增加或修改一个功能。你只变更某一个服务。通过开发可独立测试或部属的更小增量的应用，你可以让你的应用和服务更快的上市。
更容易排错和维护
微服务还使排错和测试应用变得更容易。有了这些更小的经过持续交付和测试流程的模块，你交付无错应用的能力大大的提高了。
增加投资回报减少总体拥有成本
微服务还可以让你优化资源。有了微服务，多个团队在不同的服务上工作，使你可以更快地部署，或在需要时挖掘更多。开发时间缩短了，而你的团队的代码将更易于重用。通过解耦服务，你不必在昂贵的机器上操作。基本的x86机器就能做。微服务提升的效率不仅减少了架构成本，还最小化了停机时间。
持续交付
不像单体应用，它有专门的团队致力于单一的功能，比如用户界面、数据库、服务器端逻辑、技术层，微服务的跨功能团队用持续交付模型来处理应用的整个生命周期。当开发者、运营、测试团队同时在单个服务上工作时，测试和排错变得容易和迅速。用了这个增量式开发的方法，代码被持续地开发、测试和部署，你使用现成的库代码而不是重新发明轮子。
微服务并不适合所有的企业
接受了微服务的企业已经意识到显著的好处，忽视这个的机构可能会落伍。尽管微服务看起来很有前途，并不是所有的企业都能从微服务获利。确保你的企业有足够的能力管理它。以下是给机构的一些提醒。
你需要配备快速调配和应用部署
有了增量式开发和持续交付，微服务让你的机构长葆活力。员工应该立即调配资源以跟上最大化利用微服务所需的步伐。如果部署服务器要数天或数月的时间，你就会陷入严重的麻烦。同样地，你应该快速地部署新服务和应用。
稳健的监控不能少
因为每一个服务都依赖它自己的语言、平台和应用程序接口(API)，你将安排多个团队同时在你的微服务项目的不同实体上工作。你需要稳健的监控来有效地监控和管理整个架构，因为如果你不知道服务什么时候会出故障或机器什么时候会停机，当这些情况发生的时候根本就不可能追踪。
你必须接受开发运维(devops)文化
在跨功能团队中工作，你的业务应该加入开发运维实践和文化。在传统的场合，开发者专注于特性和功能，而运营团队则掉入了生产挑战的陷进。在运维里，每个人都为服务的调配负责，当然也包括故障。
测试时很复杂的
有了微服务，测试不再是直接的。每一个服务都有它自己的依赖关系，有些是直接的，有些是传递的。当功能被增加的时候，新的依赖关系会产生。要关注所有一切变得不实际。还有，当你的服务数量增加的时候，复杂性也增加了。不管是数据库错误、网络延迟、缓存问题、服务不可用性，你的微服务架构最好能处理合理级别的故障。所以，适应性测试和故障注入是必不可少的。
你必须假定故障总会发生
设计时为故障做好准备是很重要的。你应该准备好处理多个故障问题，比如系统停机、缓慢的服务和不期望的回应。在这里，负载均衡是很重要的，但是有后备计划是另一个重要的选择。当故障发生的时候，陷入困境的服务应该能继续以降级的功能运行而不会使整个系统崩溃。
京公网安备 11010502049343号