微服务构建大应用

如果我们回顾一下从古登堡使用活字印刷到马尔康·马克林发明了集装箱的历程就会发现一个有趣的模式：每一次新出现的抽象和标准化都会最终在规模和效率上创造出巨大的价值。

今天的数字化革新者们也可以追溯到类似的历程，从大型计算机到独立的应用程序，然后逐步的，发展到组件可互换，一直到今天所处的基于云的微服务和持续集成的时代。

微服务是软件搭建方式上的一次尝试，放弃大规模独立应用程序，改为小规模的，松耦合的，可组合的自治单元。这种抽象的好处就是专业化，一方面降低了开发成本，提高了灵活性和质量 - 同时得到非常有弹性的系统。

这种尝试不是第一次了，亚马逊和谷歌已经用了有十多年。容器技术（比如Docker），API和云基础设施的便利让微服务能够在更广泛的公司得到实际应用。

类似于Airbnb，迪斯尼，Dropbox，通用，Goldman Sachs和Twitter这样的公司，通过使用微服务，已经让开发周期削减了多达75%。概念听起来很简单，但是做起来要比看着难一些。这已产生了一个全新的由各种公司和开源软件构成的生态系统，帮助人们进行这种过渡。

近来，60名工程师领袖聚集在红杉微服务峰会，分享如何在各自公司实现微服务的故事，这些公司包括谷歌、亚马逊、微软、Twitter、Netflix、迪斯尼、Wells Fargo、Dropbox、Amgen、Citi、纳斯达克、Medallia、惠普、Okta、Gilt、Instacart，等等。

下面列举了构建和部署微服务的10个最佳实践。

决定你是否真的需要微服务

并非所有应用都复杂到有必要拆分为微服务的程度。Thoughtworks的Martin Fowler和Ryan Murray提到了“微服务副作用”，在很多情况下，微服务的复杂性阻碍了团队的生产率。有一种观点说，当你应用变得很复杂或者你团队开始超过50-75个工程师时，这种架构的好处将逐渐淡去。

让你的屋子井井有条

持续发布和自动化比微服务更重要。小巧的，灵活的团队，能够至少每天进行一次持续集成，是微服务的一个重要前提。有能力让系统自动化并经常地更新代码，这对于处理由于引入这种架构而导致的复杂性非常关键。

任命一名主管责任人

如果你不设计并管理微服务的演进，结果将是无法控制的混乱。有一个人或者一个小团队负责控制架构决策并帮助确保采用标准方式，这很关键。

谷歌有一个小的主管责任人团队，他们理解各部分如何一起工作，帮助指导新服务的创建。Twitter的Alex Roetter指出这就像“用正确量的盐”一样。你肯定不希望彻底将这项伟大发明搞得一团糟。

将微服务对应到你的业务流程中

团队应该有有限的工作内容，各系统应该遵循统一的业务流程。Melvin Conway在1967年第一次提出这个原则，今天这条规则仍旧正确。当你的服务没有直接对应到业务上，将来解决问题或重新设计时会很困难。

每个新产品都从独立程序开始

不太可能找到拆分独立程序的最佳方式，除非你已经对它了然于胸。一旦你对产品如何应用有了概念，你就可以着手分解了。今天，在如何确定服务的大小时仍旧有一些麻烦和错误，或许将来有一天有人能够用软件来帮助你完成这项工作。

渐进行动

不要把独立应用程序一下子扔了，这会导致灾难性的后果。一次只选择一部分来拆解，当这块已经能正常工作了，再处理另外一部分。有些公司的尝试过于激进，导致了功能丢失并让定位问题变得困难。

建立一个共享库

考虑在应用开发过程中建立一个大型共享仓库，包括所有服务，给团队来用。你肯定不希望同时有两三个公共服务的版本在跑。你的责任人应该帮助管理这个仓库。

应用综合监控

要管理很多部件让遥感监控更为重要。微服务监控界面非常的碎片化，现在还没有非常合适的，一些公司在开发自己的监控产品。相对于独立应用程序，微服务要求一个更加综合深层的监控。

提高安全性和可控性

更多的操作界面和复杂性对安全性和可控性提出更高的要求。考虑一下你如何授权一个人跟另一个人对话，鉴别非法流量。谁有权限工作在具体的某个服务上？在你的公司，所有的服务都能用于处理所有任务吗？共享服务如何收费和管理。

收获奖赏

当进行了成功的实施，微服务带来了在公司构建和部署软件上速度和灵活性的巨大提升，交付应用的成本更低，你的系统更加的有弹性，开发时间从几个月降低到几个周。

如果这些听起来有些令人气馁，那想想另外一个结局吧：比竞争对手更长的开发周期，更脆弱的基础架构和更慢的创新。微服务并不适用于所有人，但是 - 如果有效实施了 - 其结果对于创建持久型公司具有转折性的意义。 

阅读原文：

Get Small To Get Big Through Microservices