2千万行开源专案为何用微服务，OpenStack工程副总裁谈微服务架构难题

开源IaaS OpenStack在今年高峰会上，OpenStack基金会首席运营官Mark Collier就强调组合式开放基础架构与原生云端应用的重要性，重新定位OpenStack，摆脱过去只是提供VM运算服务开源IaaS的既定印象，更要升级变成综合各类开源元件的创意平台。

这样的架构新主张，其实与微服务所强调云端原生、元件可重复性等特性不谋而合。架构日渐复杂的OpenStack，已从最基本的运算、网络及储存元件向外发展，推出更多样化的功能模组，支援大数据、容器调度及机器学习等应用。而OpenStack本身就是个复杂结构的应用程序，也导入了微服务开发的概念，由许多功能相异、各自可独立水平扩充的服务。而这些模组再往下划分，亦是由更基本的元件组成，彼此可以互相调度、沟通。

目前OpenStack基金会在开放源代码平台GitHub专页中，其管理的专案储存库超过1,500个，从2010年诞生至今7年，程式码规模已经超过2千万行，背后支援OpenStack专案的企业也有666家。在正式环境导入OpenStack专案的组织，除了知名企业PayPal、Walmart及福斯汽车外，也不乏公立机关如欧洲核子研究组织（CERN）及英国税务海关总署。

主导OpenStack技术发展走向的OpenStack基金会工程副总裁Thierry Carrez，分别在基金会内担任过工程总监、技术委员会主席。在进入OpenStack基金会前，除了任职轮胎大厂固特异IT经理，更在Linux操作系统厂商Canonical担任Ubuntu服务器团队技术总监。我们也访问了Thierry Carrez，请他分享究竟OpenStack的专案开发如何导入微服务，以及他对微服务的看法。

 Q  企业要如何利用微服务进行架构转型？

 A  导入云端科技只是一部分，转型还包含了企业文化的改变，不单只有技术而已。像保险、银行业内部有许多老旧IT系统，但这些系统不能停止运作，例如薪资系统、报税系统，它们由一层一层规则所堆叠，还有一堆例外条件要处理，全部替换除了技术上困难，成本也很高。

因为金融业是高度管制的行业，某家法国银行利用OpenStack，一并整合新旧IT系统，除了能存取大型主机应用程序，也可以连接外部的云端服务。如此一来，不仅让既有内部IT架构维持完整，也不需要改变现有的网络、资安架构。在微服务转型上，我们看见企业会保有老旧的单套式（Monolithic）系统，同时利用微服务建构新兴网页应用程序，并且让两方建立沟通。单套式架构未必需要很敏捷，因为它太老旧，很难厘清该系统的运作方式，只有推新服务才很讲求速度。因此，前端系统往往是最先支援云端技术。

 Q  未来OpenStack也会拥抱微服务或云端原生的IT架构吗？

 A  OpenStack本身是一个很复杂的应用程序，由许多不同的服务组合成，像是Nova（运算）、Neutron（网络）、Cinder（储存），各自也可以水平扩充。而这些模组，也是由许多可互相沟通的小元件组成，彼此可以互相调度。

所以，OpenStack本身就是一个微服务架构，也因此，可使用一些容器调度工具如Kubernetes调度这些服务。

现今有些企业想要让这些元件在非OpenStack环境执行，例如，让Cinder、Neutron、Keystone等元件在Kubernetes环境执行，所以OpenStack基金会也必须提高这些模组在基础架构层中的可重复使用性。

谈到云端原生应用程序的开发，OpenStack的目标是给予开发者多重选择，例如使用VM、容器交付服务，或是支援Kubernetes、Mesos等容器调度框架，让企业选择最适合自己的技术。

就如OpenStack基金会首席运营官Mark Collier所说，OpenStack是开放基础架构，新兴技术会不停地推出，OpenStack必须支援不同的技术，才能满足应用程序开发者。例如，当今容器技术的使用需求火热，但是未来可能又朝Unikernel、Microkernel发展。

 Q  OpenStack专案开发也有导入微服务架构的想法？

 A  没错，OpenStack的专案开发都有导入微服务的想法。不过我们也有碰上一些困难。举例来说，要让OpenStack云运作，必须要有数据库、讯息伫列（Message Queue）这些基本服务。但是如果要想扩大规模或调度分散式服务，这些元件的功能还不足提供某些功能，像是跨节点的网络路由任务。因此，OpenStack需要一些元件，可以负责调度任务，或是横跨系统执行组态设定。

但是我们发现，OpenStack专案开发犯了重新打造轮子的错误，想要重新解决一些他人过去曾碰上的问题。这也让OpenStack基金会开始思考，如果OpenStack要变成一个云端原生应用平台，究竟还缺乏哪些技术。

过去OpenStack基金会并不认为这些事情很重要，但最近我们开始想纳入一些开源工具，也把此需求上呈到OpenStack技术委员会。例如，在5月时，OpenStack就决定把ectd整并至其架构中。

透过etcd，Cinder模组有相当大幅度的升级，像是不同的VM可以同时存取一个储存元件，未来Nova元件也会整合etcd。

 Q  用微服务有什么代价？

 A  其中一个代价就是复杂度。以单套式架构而言，当所有系统都部署在同一个资料中心时，开发者很清楚系统的运作机制。但是微服务是由许多互相沟通、彼此牵连的服务组合而成。

虽然微服务让开发单一元件更简单，但是开发者最终得面对一个极其复杂的IT系统。因此，必须要有一个监控平台或机制处理复杂度的挑战。以自身经验出发，我以前相当熟悉网络架构的机制，但现在Neutron模组变得非常复杂，连我也必须很努力，才能弄清楚它的运作。

复杂度的挑战永远都在，分散式系统的本质就是如此。现在也陆续有开源专案在解决这些问题，像是Kubernetes除了可以调度、部署微服务外，也能让它们水平扩充。但我认为，现在还需要一个应用程序层，用于除错、分析及监控这些微服务应用程序的运作。因此，有些组织会选择一并使用单套式及微服务，因为它们知道单套式架构结构简单带来的好处，但同时，这些企业也想有能力建置各类功能单一的元件，用于架构复杂的微服务应用程序。

 Q  OpenStack跟其他微服务平台定位上的差异？

 A  以OpenStack的角度出发，开发者永远都需要IaaS，相比其他人比较专注于应用程序开发者，OpenStack的定位是基础架构提供者，以此为基础，让应用程序开发者可以架构其他解决方案。

OpenStack并不会与Kubernetes或OpenShift竞争。反之，这些厂商也不想与我们竞争，因为它们并非锁定解决基础架构的问题。例如，Kubernetes的运作，仍然得靠公有云AWS、Google等，或是私有基础架构VMware或OpenStack。

因此，OpenStack的任务在于，简化Kubernetes在OpenStack上部署的困难，让开发者进一步能打造机器学习应用程序、无服务器平台，或是利用容器建立多租户架构。

 Q  微服务有什么好处？

 A  微服务的主要好处是让开发者自行决定IT架构的规模，无论是大规模部署，或是小规模部署都可以，这是它的重要优点。

开发者也能针对特定服务，独自水平扩充，或是独立更新某些系统元件，让开发流程变得更加敏捷。

不仅如此，微服务也适合用于边缘运算的小规模应用情境上，让应用程序可以部署在规格普通的硬件装置上执行。但边缘运算应用需要高度客制化的开源软件才能解决这些问题，不太可能仰赖VMware、AWS这类厂商的庞大解决方案。所以我认为，OpenStack在边缘运算有新机会，现在我们也有专门的边缘运算工作小组在规划相关事宜。