本文讲的是为什么公司采用微服务以及他们如何获取成功【编者的话】微服务架构设计是最近讨论最热的话题。随着最近几年互联网行业的迅猛发展，随着公司或者组织业务的不断扩张，需求不断的增加以及用户量的不断增加，单块架构的优势已逐渐无法适应互联网时代的快速变化，面临着越来越多的挑战。我们是否要开始使用微服务架构来避免单体式架构带来的挑战？微服务架构真的是我们想要的吗？什么样的场景应该拥抱微服务架构？本文从非技术的角度阐述了对微服务的理解，为什么公司选择微服务架构设计，以及分享使用微服务架构的成功经验。
这篇文章研究的是在非技术因素下，为什么公司选择微服务架构设计。在技术驱动的环境下，公司必须学习采用新的架构保持敏捷，从而满足公司核心业务的增长需求。
向微服务的转型通常被认为可以突破现有系统局限性。在大多数场景下这种转型是没有问题的，由于业务需求层次的升高和团队的动态流动等因素也会推动公司朝这个方向转型。
这篇文章涉及到转型的动机，具体迁移的路径，什么是最终的成功转型，在转型中需要权衡什么等。
对于那些经历过着个这种转型的人来说，他们已经很熟悉我们大部分的讨论内容。分享这些经验出来，也让其他的人从中学到到如何在微服务实践中避免踩坑，而不仅仅对是否迁移到微服务做出决定，这一点是相当重要的。
在讨论这些以前，我们先来认识一下什么是微服务。
什么是微服务
具有有界上下文松耦合结构的面向服务体系设计结构。
——Adrian Cockcroft
概括来讲，微服务是分解大型应用程序为单一职责的小服务的一种软件设计模式，这种模式可以满足网络交互自助构建与管理。
在以前的
请输入链接描述
一篇文章中，我们曾经讨论过什么是微服务、微服务的优势，以及
微服务在系统中扮演的角色
。这篇文章中我们假设您已经具有了解微服务的基础知识，不过如果您真的确实是第一次接触微服务，也可以先阅读这篇对微服务
介绍的文章
。
如果您想了解关于迁移到微服务技术方面的问题，您可以参考Matt Heath在Hailo上发表的博客
Journey Into Microservices
这里也有一篇Martin Fowler发表在博客上很好的
文章
，它是关于微服务背后的一些基础理念的，这里可以阅读。
下面让我们来深入讨论下选取微服务的动机
动机
速度、伸缩性、敏捷
您是否有听过公司有这样的要求：
"把项目慢下来”
似乎还没有听过吧。
通常情况下我们要在尽可能短的时间内交付高质量的产品。这种要求听起来简单，但做起来相当困难。一个公司的产品是不断在进化的，“功能完善”是一个持续性的目标。我们在不停的定义新的需求，整合新的合作伙伴，在多区域环境处理纷乱复杂的业务需求，业务也在不停的发展成长中。
早些时间，团队人员的数目还不多，基础代码量也很小，产品可以聚焦在一件事，并且把事情做好。在业务的第一个周期内，经常会有快速产品的迭代，这是在创业过程中很正常也是最常见的特征现象。
随着公司业务的增长，部门人员的数量也在不断的增加，公司的焦点逐渐从开始的专注做一件事转移到新的市场，在内外的驱动下，需求的规模也是在不断的成长。在当前的系统环境下，那些当初看起来很厉害的地方，随着时间和业务的升级也开始变的不能满足目前的需求。
过去需要几天就可以完成的工作，现在却需要花费几周甚至更长的时间完成。团队的同事在并行处理事情，在同一套代码的基础上处理着错综复杂的业务逻辑。
整个系统的开发人员都害怕发布生产环。业务高峰的搞高请求量可能会导致整个系统的坍塌。项目在Q1就立项开始，发布时间为Q2或Q3，这样就不可避免的全部慢下来了。
公司内部的执行不再高效，有些无效的事情又不得不做。
技术团队可能会决定通过不断的迭代将系统拆分，这些对系统多少会有点帮助，但是6-12月以后仍然还是会意识到系统中存在先前一样的问题。
在增加新的需求场景下，而保证不引入新的问题，这是几乎不可能的事情。
很多公司在他们的开发周期中都会遇到这些问题。从长远来看，现有的组织架构和技术架构已经成为公司发展的阻碍，从商业的角度看这一点愈发明显。
保证良好的软件质量和快速的迭代开发速度，公司达到这一目标的立场是唯一的。但是目前公司的来自自身的限制比市场和竞争对手还要多一些。
在这一点上可以清楚地看到有必要解决这些问题，以便公司可以在某种程度上能够执行其结构化。
重构之路
无关技术，和人有关。
虽然动机已经十分明确，但是在达到目标之前，首先讨论下现存问题对系统的直接影响也是非常重要的。
团队。
如果我们在没有完全理解现有系统的症结所在，却过快地投入设计新的系统，这样做不仅会得到错误的构建结果，而且还会消耗大量的时间和成本。
这对组织的每一个部分影响是不同的。甚多时间你听到的不是技术问题，而更多的是团队合作，目标优先级等。
技术可能是产品供给中的核心部分，但是现在公司越来越关注的是人，以及人与人之间怎么合作完成工作。
寻找专家的意见
在讨论公司问题和解决方案时，团队内部的建议是很有必要的，同时也有必要听取外部专家的一些建议。这些外部的专家可能已经遇到这些问题，他们的经验是非常有价值的。
这也并非意味着要寻找专业的咨询公司。重构也不是什么新鲜的事情，有很多经验丰富的专家或者来自其他公司的个人在这条路上有经验，他们都可以提供一些独到的见解。
邀请这些人花上几天的时间来公司看看具体的技术，在如何实施的问题上，他们也可以提供一些个人的意见。通过寻找一些外部的专家并听取他们的建议，这样你就可以知道下一步如何去做。
在某种情况下，微服务也可能并不是所需要的解决方案。很多缺陷可能与产品的实施过程有关，可以调整关注产品的生命周期管理一些其他一些小的技术变更。
关于什么是正确的方法，您也可能会得到完全不一样的观点。这是因为过去的经验放在了特定的场景下，例如快速的收入增长，高级工程师对于过去架构的经验等。
聆听多种多样的经验和意见是非常重要的，然而最终团队要根自己所处的场景做出适合自己的判断。
现有的模型
如果您已经决定好重构的方法，随后就是要查找专家在这个领域以前工作，以及他们做过的一些模型。
下面的事情需要知道：
- 什么样的团队架构和工作职责
- 什么样的技术选型
- 如何构建体系架构和实现伸缩性
- 遗留的系统如何迁移
最近几年已经出现在像NetFlix这样迁移微服务平台的模式公司，他们也是积极讨论这方面话题的公司之一。这个重构过程也包括了将服务迁移到亚马逊公有云平台。
另外像Spotify也在工程师文化和结构化实践上做了论证。在技术圈子，社区，组织中会讨论很多成功的案例，这些都提供了很多帮助。
原型设计
最开始一股脑想把完整的产品做好是不可能的，做好的开始方式是先做出原型设计。
在这个阶段，工程师们应该被给予时间认识需求，测试潜在的技术问题，设计架构模式等。在理想的条件下，2-4周内就可以给公司提供解决方案例子，平台演示的例子，概括的实践方案等。
团队之间很有必要对于什么该做，什么不该做这样的问题相互讨论一下，而不是小圈子内部就得出结论。
整个公司的人最终都是新平台的使用者，所以他们有权利对他们每天将使用的系统发表自己的建议。
这个阶段还有很多是要学习的。团队现在的技术能力和经验是否能打造比以前更好的系统。
预计构建第一版系统的时间是什么时候，评估是否也要解决目前公司正在面对的一些问题。
以上任何一个问题都有可能出现在下一个阶段，所以我们还是建议解决当务之急，从而最大限度地降低成本风险。
如果现在系统已经达不到新的要求，也不要害怕重新退回上一步重新评估系统。
如果原型设计阶段成功，现在就可以开始下一个步骤：构建新的平台，并验证是平台是有效的。
一个新的架构
回首过去，几个工程师手动拼凑起来的现存系统已经成为一种独特的架构，只能公司少数的工程师维护。
有系统备灾方案吗？有系统自动故障转移方案吗？系统从头开始重建需要多长时间？系统的可伸缩性怎么样？安全等级呢？
以上所有的问题可能没有一个能自信回答：YES。在讨论问题之前就该抓紧时间寻找机会解决上述问题。
所有，需要什么呢？
不要有过去的包袱，需要一个高可用的自动化本地云平台即可。
正如前面所述，构建可伸缩的微服务平台和工具已经存在，随着原型设计阶段的结束，团队应该已经规划好一个可复用的模式成为全新的系统基础。
由于这是一篇非技术的博客，技术实现的细节我们不做详细的探讨。如果您愿意深入探讨，可以去做进一步的研究。
迁移之路
如果你曾作为服务的提供者，您应该知道服务的连续性是至关重要的。任何服务的中断影响到客户的体验，这些都有可能影响整个公司的最终的收入。
如果你想确保整个迁移的过程，服务水平规则（SLA）是常用的方法。请记住，关键的业务是首要的任务，但是在迁移的过程中也要维持SLA，以达到运行时间和发展时间之间的平衡。
如果团队花费大量的实践把遗留的系统迁移到新的系统上，实际上公司就无法执行其他重要的业务需求。每个人都应该在开始迁移旅程前慎重对待这方面。
说到此处，无论你怎么区分，迁移总是需要时间的。对现有遗留系统做尝试、测试。在新的平台上，重新构建出一套新的微服务版本 ，然后在逐渐迁移过来。
这里有几个重要的点，还需要注意一下：
- 不要把整个公司的关注点都放在迁移上。抽调一个单独的团队构建原型设计，专门处理迁移这件事情。这样公司大多的团队继续专注于现有的项目上，尽最小的打扰他们正常的项目进行。
- 选择一个好细节容易迁移的项目。团队要对第一个迁移的项目有比较深刻的理解，它将如何使用新的架构，以及如何做到遇到遇到重大问题，及时回滚。
- 设置可以显现的里程碑。几周时间显然没有足够的时间迁移第一个功能，但是如果在这件事上持续了6个月时间，这显然是出了什么问题。3个月制定迁移计划、编写软件、测试完成、发布生产提供服务到新的平台，这显然是一个很好的时间跨度。
成功迁移一个功能或者服务后，技术的方向，里程碑，团队的需求这些都会成为一个相对固定的模型。
可能需要几个月甚至几年的过程来决定如何优先迁移什么项目。每一个人都应该明白，这并不是一夜之间就可以完成的过程，产品的特性或者开发的需求都是项目重构的一部分。
平台即服务
开发者是消费者
在迁移的过程中，实践成功经验的模式可以像剧本一样保证迁移的质量。平台的参与人员要对他们所参与的服务开发有一定层次的理解。
其余的一些公司应该对于迁移的进展保持循环，并且在这个过程中掌握关于新平台是如何工作的知识。
现在我们需要努力地吸引他们增加对开放平台的理解并且开放平台给他们，这样他们可以参与到自服务的迁移，或者在平台上构建自己的产品。
这就是我们真正开始平台及服务的必要性。
平台团队的必要性
你听说过Pass作为某种形式的承载，像攻击正在运行的应用程序。这样一个系统的好处是，他可以让你聚焦在产品的研发上，尽量少的关注基础设施的管理。
当内部运行一个微服务平台，你会得到同样的优势。
团队应该专注于教辅业务的价值，而不是自动化和管理分布式系统的复杂性。
平台团队的主要目标是通过API看板和开发工具提供内部平台服务，同时保持系统的可用性和扩展性。
针对以上方法有不同的观点，例如，Spotify提供了数种语言架构，每个团队可以选择他们自己的技术和管理他们自己的基础设施。
Google、Facebook、Twitter、Netflix和Hailo已经选择了备选模型，模型就像一个云提供商，为公司提供一套服务。
与任何选择一样，这是一个权衡的结果。这是时间和灵活性的权衡的结果，如果不采用平台及服务的模式，时间是节省了，但是提供的服务就不会具有灵活性。
基于他们的技能、经验，和他们认为的最主要的事情，公司在内部合理说明这些决定，论据可以有任何一个方法论组成。
自组织团队
在微服务强大的优势下，功能开发和测试新想法应该快速实现。设想任何24-48小时变成都可以成为马拉松编程，这可以变成一个常规的事件，创作出新的产品。
真正利用微服务优势的一个方法是自组织团队想法的出现。 大多数情况下会有任务组或者产品组来自主经营，并关注长期的目标，自组织团队是扩充这样结构的一种方法。
举个例子，一组3-4个技能互补的员工来自于多个团队，需要解决一个确定的难题，或者是他们对新功能的一个想法，非常清楚地把想法开发出来。
经过他们经理的允许后，为了构建完成一个解决方案，他们组建了一个为期两周的团队，他们可以重用平台现有的微服务，充分利用整个自服务加快整个过程。在一个周期的最后，在没有其他团队的协助下，他们为产品输出了一套新的服务，更重要的是他们没有使用现有程序的一行代码、
如果这样解决方案成功了，就为他们创建了永久的团队，为进一步的产品开发提供了依据。
自组织团队是一个真正有微服务优势驱动的巨大组织的放大。自组织团队的另一个名字是工会，这是来自于Spotify的称呼，Spotify把他作为组织构建的一部分。
这里
深入学习Spotify的模型。
成功是什么样子
从开始到成品往往只需要几个小时或者几天，而不是数周数月时间。
将运行中的产品从一个平台迁移到另一个平台是一个漫长而又艰辛的过程，所以衡量什么是成功并不能以迁移的结果作为唯一的衡量标准，而是应该考虑到通过这样方式逐步是否逐步实现目标。
回顾前面讨论的问题：
- 放慢开发的过程
- 跨团队之间的合作
- 脆弱庞大的软件
在迁移进行中，所有的问题都应该被立即解决， 通过分布式系统技术架构，微服务提供了组织速度规模和灵活性的形式。
庞大的应用程序被分为较小的应用程序，其中每个小的应用程序都可以由不同的团队独立完成并且发布，每个团队不需要了解其他团队的开发服务技术细节，只需要严格按照API的规范调用即可。
由于分工协作和自主运维，团队有可能会实现更快的产品周期，哪些地方需要出团队协作，简单的调用别的团队提供的API即可。
进一步说，平台应该提供一个产品团队可以利用的高可用和全局扩展系统，而不用考虑构建分布式的细节。
在最短时间内交付一个高质量的产品的能力仍然是衡量成功的一个标准，但是扩大组织和技术的能力也成为衡量成功的另一个标准。
在经历这个过程中许多事情都将会发生变化，有些是在你的控制之下，但是许多并不是的。市场可能已经进化，公司发展到一定规模后，优先级可能也发生了变化。
重要的是发展和适应这种变化，不要害怕尝试调整团队和推出新功能等等。
平台是一个坚实的基础，应该允许你以任何可以想到的方法快速行动，推出新的计划，迭代的改造业务，把它作为一种竞争优势。
大爆炸
大爆炸意味着一家公司的灭亡
任何关于重新架构的帖子，要是不说两句关于大爆炸的话，就不算完整。
大爆炸产品开发是只需要发布一次就能完成的过程。整个产品要竭尽全力从任何0开始在6-12月内完成，但是很可能时间会大大延长。
通过这种方式在重新架构的过程中本质上涉及了重新创建整个已存在的产品，当完成的时候，已经转换到了新的平台上，你可能已经想象到无数种可能出错的方法了。
建立大爆炸的方法学可能是一个理智的决定，但是大多数情况下它像是一个缓慢增长的野兽，没有人能看得到未来。功能完整被认为是无限的列表，产品需要一些调整，有时只有一小部分，有时会有较多的调整，产品不可能完全做好了才会准备着要发布了。
我们都知道高失败率和这种开发形式有关系，大量的时间和资金可能被浪费在大爆炸开发中。
团队如何了解他们正在构建的产品在今天的市场上实际是仍然可行的呢？机会可能会流失，在没有任何反馈的过程中很难告诉你是否仍然在正确的道路上走下去。
当开始重新架构的时候，我们知道最终的目标是什么。但是要达到最终目标需要我们将它分解为若干个较小的可以在短时间内完成的交付物。
无论如何要避免大爆炸，目的是两周做为一次冲刺，一个季度里程碑庞大的工作完成一个交付物。每个周期使你更接近终极目标的同事在过渡时期产生真实的结果。
权衡
微服务不是银弹
当提到扩展技术和团队时，微服务就没有高招了。成功是个变动的目标，适用于10人团队的技术对于100人团队就不一定合适，对于100人团队甚至更多就不合适。同样可以说一个公司内部大多数的选择无论如何都是和技术相关联的。
任何事情都有一个折中的方案，管理微服务架构很明显会要求更多的工作，但是对于一个执行速度和规模快速增长的系统而言，它的好处也是显而易见的。
我们看到在一些组织内部已经自然转向了微服务的使用。微服务到了一定规模后，管理整个系统和降低人与技术的权衡变得越来越困难，是值得为他们所提供的好处。
在我们得知微服务之前，在GitHub和开源软件成为流行之前，回到它被认为是一种竞争优势保持着一切神秘感的时代里，许多公司已经通过反复试验经历过这些知识。
谷歌就是最好的例子，由于需求量的快速增长以及同那个年代的巨头（微软、雅虎）竞争，迫使他们去学习、去迭代、去发展。
我们中的大多数公司都从未达到过Google的规模，但是他们大量的经验和知识有难以想象的价值，我们可以利用他们成为我们的优势。
越来越多的公司在公司发展的某一时刻开始选择使用微服务，不管他是否对大规模的需求和开发有显著的帮助还是更多的迭代和有序的方法。
显而易见的是，使用微服务和随之而来的许多挑战需要权衡，没有一条道路可以直接到达成功，但是我们现在看到的模式和过程的出现可能会导致微服务成为一部分公司通向成功的理想方式。
如果你对使用微服务感兴趣，请联系
Micro
来帮助你增加成功的几率，利用技术满足你的需求。
原文链接：Why Companies Adopt Microservices And How They Succeed（翻译：张亚龙）
原文发布时间为：2016-09-05
本文作者：张亚龙
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：为什么公司采用微服务以及他们如何获取成功
