转载

实现云原生应用，先理解架构微服务化

Cloud Native直译过来是云原生，是面向云环境而设计的软件架构。腾讯云布道师刘永峰认为云原生并不是新的技术，它是基于微服务架构思想、以容器技术为载体，一种产品研发运营的全新模式。InfoQ围绕微服务如何实现云原生应用为主题对刘永峰进行了采访。

受访嘉宾介绍

刘永峰，腾讯云高级产品经理，布道师，十余年的产品及研发管理经验。国内最早一批从事可信计算研究的探索者。曾就职于中兴通讯，负责流媒体Server后台架构设计，Linux内核相关的研究。2011年起加入腾讯，一直从事公有云的产品设计，云计算市场趋势分析和研究，云计算技术的推广与普及。在技术和产品领域均具有丰富的行业经验。目前主要关注Docker，微服务，Cloud Native，企业云化趋势等相关领域。

InfoQ：能否根据您的理解给微服务下个定义？微服务需要“微”到什么程度？

刘永峰：微服务，按照比较学术化一点的解释是一种面向服务的，有特定边界的松散耦合的架构。我个人观点，可以从以下三个关键点去理解微服务：一、每一个微服务是一个 独立的自治系统 ，不依赖外部组件能够独立运行。二、对外 只能通过API 提供服务或者获取服务。三、 粒度足够小 。

到底微服务多大才合适，是一个经典的问题。我认为这个没有固定的答案，而是根据自己的业务特点，团队组织方式决定的。康威定律提到，有什么样的团队组织方式，就有什么样的业务架构。所以，首先， 微服务的粒度和团队组织方式是相关的 。其次，粒度大小， 与业务功能的构成相关 。一个微服务，在划分上，尽量做到一个模块中的业务高度类聚集，和外部模块能够做到松耦合，这样会有更多的灵活性。最后，微服务的粒度，还 和数据有关系 ，一个微服务，尽量不要做到和外部频繁的交互数据，因为大量的API交互对性能和可靠性都会有影响。

InfoQ：相比SOA而言，微服务的重大优势是什么呢？微服务普遍适用于各种需求各种架构吗？微服务是未来吗？

刘永峰：微服务，是一种去中心化的架构。微服务一般和更细粒度的容器去配合使用，并且和云天生有很强的共生性（又称云原生：Cloud Native）。从架构的发展来看，其实一直是朝着去中心化的趋势发展的，从早期的集中式架构，到分布式架构，再到现在更细化的微服务。去中心化的架构，具备更强的灵活性以及鲁棒性，并且更适合云的特点。

微服务化比较适合无状态，对延时要求不高的业务场景。电商类的应用可以将业务打散，拆分成各个服务，服务之间可以通过API进行交互。但是，对延时敏感，或者数据无法拆分的场景（譬如大数据处理、视频直播、一些游戏类）而言，微服务是无法发挥其特色优势的。

微服务可能是未来一种非常主要的，应用广泛的架构，但是并不一定说它会统治一切。微服务是具备自己的一些应用场景的。

InfoQ：您认为微服务化改造中最大的难点是什么？

刘永峰：微服务在实践过程中，最大的问题是团队之间的运作和管理的问题。刚才我们提到过康威定律，业务架构，总是和团队组织架构想匹配的，当你把一个大的系统，拆分成小的服务时，团队会随之变化。

团队组织调整之后，就需要解决团队的人员管理问题，需要让团队的成员适应微服务的开发模式。因为微服务，对每个程序员的要求是比较高的：每个程序员的权责会更明显，需要标准化接口、书写规范文档，而且一般需要有DevOps的工作。

微服务化的改造，难点不在于没法拆分，难点在于很多的人的思想在于停留在以前的架构思想下。突然间大量的改造，公司人员会有非常大的不适应性。 我的建议是，逐步改造、持续迭代地改造架构。 新的业务、新的团队可以独立地采用微服务化的方式去运作。这里我举个典型的例子，某个企业进行了架构微服务化改造之后，每个团队会负责两三个关联性比较强的服务，但是团队往往会倾向于把这两三个微服务合在一起。这种情况下组织架构与业务架构不匹配，所以业务架构必然会朝着更匹配组织架构的方向去发展，这就是康威定律在起作用。

InfoQ：怎么处理微服务与外部相连，并获取数据的问题？

刘永峰：我的理解，在设计时就需要考虑到微服务有哪些数据需求（见问题一的第二小问）：微服务都是通过API对外提供服务，本身是一个独立的自治系统，所以不存在需要与很多数据中心相互连接的情况；如果需要通讯，直接适用公网连接就可以了。

换句话说，微服务和微服务之间的数据通讯是通过API调用的。没有所谓的内部的进程间、共享信号、共享内存队列的模式。一个微服务对外提供的服务一定是封装好的、接口式的。

InfoQ：如何看待微服务、容器技术的两者的关系？两者结合会带来什么样的新趋势？

刘永峰：目前去中心化的思想越来越广泛，微服务与容器就是很好地践行了这种思想。微服务是一种架构思想，而容器、或者说以Docker为代表的容器技术，是一种运行的载体。容器天生适合细粒度的微服务，容器的管理和分发需要Docker的支持。两者结合，再结合团队组织的一些思想，其实就是云原生Cloud Native 所倡导的东西。

为什么会出现这种趋势，这和目前创业公司的产品研发模式是相匹配的。随着互联网与云计算的发展，什么样一种架构或者产品研发模式是适合云的模式的？是传统的集中式架构吗？分布式架构吗？我们可以看看现在创业公司的一些特点：完全基于云端，轻资产，小团队作战，快速的产品迭代。要适应这些特点，就必须基于云的原生特点去设计应用架构，所以微服务和Docker的发展的新趋势就是去实践Cloud Native。

但是并不是说所有的构架都要顺应这样的变化趋势。对于传统的IT公司，一个部门数百人做一个项目，每个小团队负责一个小模块，最后将各个模块整合在一起成为一个新的项目或系统。新版本的发布周期是半年或者一年，那这样的模式下，集中式架构可能就更适合他们一些。因此， 架构还是要和公司的组织架构相契合的。

InfoQ：您刚才说微服务和容器结合会发展出Cloud Native的趋势，可否解释下Cloud Native？

刘永峰：到了云时代，全部应用基于云去构建。这时再套用传统的研发模式也是可以得，但是并不是那么的匹配。Cloud Native是指云原生的应用架构，是专门针对云的架构。它主要包括三个部分，一种全新的架构思想（微服务），一种业务运行管理模式，以及一种团队组织管理方式。关乎DevOps、小团队、敏捷开发。Cloud Native既不是一个新的技术，也不是一套新的架构，而是产品研发、运营的全新模式。它是在云的生态场景生长出来的，和云的关系是一种鱼和水的关系。

当然，Cloud Natve也总是不停的在发展过程中，有可能未来还会融入到一些更新的东西来。

InfoQ：能否选出三个对云应用开发最具重要意义功能呢？

刘永峰：我这里给出我自己对云服务三个觉得最有意义的功能： 负载均衡、API、快照 。

负载均衡：这是对容灾扩展非常重要的基础功能。正常工作时根据策略分发；出现问题时进行容灾；需要扩展时，在运营中动态地横向扩展。负载均衡开源技术比较多，理论上是可以自己去实现的；但是具体搭建实现比较困难，怎样确保性能稳定性。一般建议还是使用云服务商自带。

API：云的未来发展，应该想我们用电一样，有插座就可以用电。有了API，就可以即时获取云；企业不需要去动手操作调用，不需要去理解API背后的细节。比如腾讯云现在提供的人脸识别服务，使用者通过API就可以使用了，不要你自己去具体实现人脸识别。

快照：某个时刻可以拍照留存，在出现问题的时候，可以恢复。

InfoQ：您提到容器天生适合细粒度的微服务，那么可以谈一谈Docker都有哪些场景化应用吗？

刘永峰：我认为有以下五类应用情景：

传统软件SaaS化：单一总线型->多租户（软件的设计要求很高） ; 克隆【容器化之后就很容易去改造】，微服务+Docker。可以在线上生成架构，不需要去服务器上配合。Docker的粒度很细，节省资源
企业私有的PaaS平台：减少人力成本，提升效率；不需要底层的运维。
企业级的AppStore：通过容器开发、分发应用。
间歇式执行任务：临时开启容器，用后再销毁。腾讯的大数据就是通过这个来实现。同时，也可以用它来自动化切换不同的场景，腾讯云的客户微影时代，白天跑业务，晚上跑大数据。
构建微服务：这点我们在上面有提到。