从单体应用到微服务的开发旅程

特别说明

这是一个由simviso团队进行的关于架构演进的云原生分享的翻译文档，这个主要是关于Service Mesh 的分享，分享者是Kong这家公司的CTO。
这家公司有一个著名的开源项目：https://github.com/Kong/kong

让 我们一起来学习下这家CTO是如何从单体应用架构过渡到微服务架构的，Kong又做了哪些事，K8S在其中又做了什么角色，什么是状态机（基于事件架构得到一种设计），在这个过程中又会遇到哪些坑，哪些经验，尽在视频分享中

视频地址：

【国外前沿技术分享-云原生专题-中文字幕】从单体应用到微服务的开发旅程-上

【国外前沿技术分享-云原生专题-中文字幕】从单体应用到微服务的开发旅程-下

视频翻译文字版权归 simviso所有：

顺带推荐一个专业的程序员后端微信群的圈子：

前言

我叫Marco Palladino，我是Kong的创始人，同时也是这家公司的CTO

如他所说，我来自San Francisco California， 今天我想和大家讨论下Service Mesh

为了打造出适合现代化的架构体系，我们的架构组织采用了Service Mesh来做过渡

我想说的是，当我们的企业变大并通过拆分变成分布式管理之后，那这个企业组织就会变得像多细胞生物一样复杂
（由一个单细胞的形式分裂成多细胞进行协作，整体上看去还是这一个生命体）

事实上，无论是我们的团队还是软件，一旦复杂了，都会去做解耦并进行分布式化管理

可以想象一下，在使用service mesh实现架构现代化的过程中，它不仅仅只是技术采用这么简单

我们的软件开发方式也因为以下三个方向而发生着改变

其中一种是技术上的更新换代

第二种是组织结构上的过渡

所以架构组织该如何去改变才能去应对新的微服务架构

也就是说，我们之前对单体架构系统所做的操作模式必须进行改变。即我们不能以之前的方式去部署，扩展，版本化和文档化这个全新的微服务架构

这三个方向正在改变我们开发软件的方式

随着docker和kubernetes在2013和2014年的先后发布，一场真正的软件革命也就开始了

Docker和 kubernetes为我们提供了一种全新的创建应用的方式
随着时间的推进，基于它们，我们可以以更好的方式来对这些应用进行拓展
不仅仅是从技术上带来的好处，更重要的是可以作为我们业务拓展的首选

事实上除了技术层面，在这场演讲中我会来谈下我们想要实现的业务目标

如果我们不能在实现业务目标的同时协调新技术的使用，那么我们也就没办法在技术转型上走下去

在这个过程中，我们必须变得更加务实才行

这是一个从单体架构服务到聚合服务（比如Maven多模块）再到微服务化的过程 Service Mesh就好像一个口袋
口袋里装了一堆的糖果，每个糖果都是一个微服务，每一个微服务可能是我们正常实现的服务，也有可能是由函数式实现的服务

同时，API也会改变它们在我们系统中的角色

我们通常以API为粒度进行APM（Application performance monitoring）性能监控管理。
自从2007-2008年移动端问世起，我们需要一种方式去和我们单体应用进行交互。于是我们才有了north-south traffic（南北交换，通常指多端与服务器之间的数据交互，也就是说我们可以通过外部开发者或移动端APP或外部其他形式来访问服务器，重点是外部）

我们要对我们的软件进行功能解耦，此时API在我们的系统中扮演的角色也就越来越重要

East-west traffic（东西交换，和上面相比，重点是内部），这个通常是指我们不同团队所开发的系统以及不同系统产品之间所产生的数据交互
接下来，我们将讨论使用 Service Mesh来对数据层和控制层进行分离，以此来不断的优化扩展我们的系统

过渡微服务的一些相关要点

1 What does it mean?

但退一步来讲，从务实的角度出发，为什么要用Service Mesh来进行微服务的过渡

我们重构单体应用的目的是可以释放团队生产力以及提高业务的可扩展性

此时整个过渡的关键在于团队生产力以及相关业务的可扩展性

在向微服务过渡的过程中，如果我们没有做到这两者中的任何一点，那可以这么说，我们在做的不过是依葫芦画瓢
所以在做这个事之前我们必须扪心自问，我们到底是在为生产而使用，还是为了用这个技术而用

在这个过程中，业务应该是首要驱动力，因为我们写项目的目的就是为了实现业务目标
在确定业务策略然后采用微服务架构来实现，接下来，我们要确定从什么时候开始，更重要的是到什么时候结束

2 should we do it？

[外链图片转存失败(img-8G77rOEK-1564671851109)(https://user-gold-cdn.xitu.io/2019/8/1/16c4d9e908e3add5?w=1361&h=761&f=png&s=525916)]

接下来第二个问题，也是那些想要将项目转向微服务的人想要问的
我们是否应该这么做，是否应该转向微服务，是否应该放弃现在原有的架构？

从技术趋势而言，我们不得不问自己，一项技术，我们是基于实际需要采用，还是因为这个技术很成熟才去采用

过渡到微服务的过程，这可要比跑单体应用复杂得多。它难就难在一个系统包含了所有的功能，然后我们将其裂变成一群具有单一功能的系统

目前而言，我们现在几乎不再以同一种方式部署或者扩展大型单体应用
但我们可以通过将一个完整的系统拆分成成百上千个具有不同功能的单体系统来实现原本的功能

如果说目前微服务无法去解决我们在管理单体应用上的问题，那么它就会使情况变得更加糟糕

因此技术架构和团队成员必须足够成熟，才能确实的去解决存在的问题

事实上，我真的很推荐在这个过程中采取步步为营的方式过渡到微服务

基于以下几个理由。首先，通过一步步的去实现阶段性的目标，这能增长团队的信心让他们觉得这件事他们可以驾驭
同时，我们在这个过程中也可以去适应并随时改变我们的流程

同时，业务领导者也会随着过渡而变得越发自信，因为整个过渡是朝着正确的方向进行，随着时间的推移来扩展和让业务变得更加与时俱进

事实上，当我们来看微服务，来看那些大公司例如Netflix，或者Amazon
它们其实很早之前就已经转型微服务，甚至那时候kubernetes和docker都不存在

到底是什么在驱动这些公司去做这样的转型？

就拿Netflix而言，为了扩展它的业务规模并不再拘泥于一个国家和单一的用户体系，它想向全世界迈进，所以它改变了

所以这也是他们的商业目标

对于想要达成的业务需求而言，他们之前的架构并不能满足。因此他们转向了微服务架构以满足业务需求

Amazon同样如此，因为它不单单满足于卖一种东西，它更倾向于商品的多元性，因此架构的改变才能满足更为复杂的需要

因此微服务紧紧地围绕着这些业务需求。为了完成我们的目标
我们不能各自孤军奋战无论是开发团队或者是管理层。拿Amazon举例，它就是微服务的成功例子

那你们谁知道，是谁决定了让Amazon向微服务去转型？

Amazon CEO Jeff Bezos曾强制推行了六个原则，如果不遵从这些原则
那这些人就可以直接被炒了（这段话其实是讲02年贝佐斯对员工提出必须要遵守的原则性问题）

这种改变很难相信居然不是开发团队提出的，而是他们的CEO提出的改变

作为企业的领导者通过逐步的改变去完成目标，同时这样能让他们变得更加自信，这才是正确前进的方法