运维是什么？

运维是什么？

运维是什么？

其实我也不知道（身为运维岗位的我自感惭愧），不过我真庆幸，在书店看书偶然发现了这本书，不过也恰逢其时，正如雪中送炭般遇见，刚刚出版不就就被我抓到了，所以毫不犹豫，蹲在地上啃了两个小时......。

大致读到了这么三点吧：

1.应用是什么？2.为什么要以应用为核心？3.怎样应用为核心？

书的第一章里面提到一个核心观念：以应用作为运维体系建设的核心

一、"应用"是什么？

微服务架构都是从单体工程拆分而来，每个产品设计初期都只有部分核心功能，随着时间推移与产品的不断迭代，产品本身会越来越臃肿，从初期一个解决某种特定场景，服务于特定人群的一个"工具"，最终演变成为一个庞大的体系，甚至是一个生态。而一个产品一旦变得臃肿，后续的维护工作会变得越来越复杂，我能想到的最麻烦的一个问题可能就是发版本。假如所有服务都放在一个工程下面，某天A团队为了紧急修复a模块的bug，紧急发布，导致B团队的b模块也跟着重启，而实际上我们知道b模块跟这个bug本身无关，但放在一个单体工程下面，就会面临这种问题，牵一发动全身。所以文章里面提到的第一个观点就是"拆"，将一个臃肿的应用拆解成为一个个的服务，每个服务又对外暴露API供其他服务调用，这样的架构就是我们常说的微服务架构。书里面给了一个范例图：

书中的一个例子，以电商网站为例，我们知道电商网站包含很多功能，如用户登录注册、产品概览、产品详情、支付/充值、售后等等一系列服务，在应用的设计初期，就可以将一个庞大的工程拆解成一个个功能模块

拆分后的模块数量与业务体量和复杂度相关，所以为了统一概念，我们将这些模块称之为"应用"。为了确保每个应用的唯一性，我们会给每个应用确定一个唯一的标示符，例如上图中的DetailServices，SKUService，TagService,TemplateService等等，后续将通过这里定义的"应用名"贯彻整个产品的生命周期，将该产品设计到的方方面面都关联起来。

二、为什么要以"应用"为核心？

文中举了2个场景：

场景一：研发团队出于业务上线需要，在运维平台申请了一些资源，比如说缓存或者消息队列（数据库、VIP、存储等等），一开始这些资源都是自己使用，所以很清楚这些资源的用途。随着业务发展，时间一长，申请的资源一多，慢慢的记不住了。后面业务交接给其他团队维护，或者原先申请资源的负责人离职，慢慢的这些资源就变得七零八碎，没有人清楚它的用途，没有人知道这个资源有没有用到，没有人能看清楚整个应用的全貌。

文中举的第二个场景是：同一个应用没有一个统一的应用名，没有以应用名贯穿整个应用的什么周期，通过应用名将所有与该应用相关的资源关联起来。开发团队认为自己只要按时按量完成产品的开发/上线即可，为了快速上线，草草的为产品或者应用起了随意起了一个名字，例如用户中心（User）。运维团队则从产品上线后的维护工作考虑，为了资源和应用配置管理方便，通常又会独立定义一套应用名体系，给产品取了另外一个名字，用户中心（UserCenter）,如果后面还有配置管理、发布、监控系统，可能又各自维护了独立一套应用名体系，而实际上我们知道无论是开发团队定义的User还是 运维团队定义的UserCenter本质上都是对应着同一个应用下面的不同资源。最终的结果就是，通过应用下面的各自资源都成为一个个的孤岛，无法将彼此关联起来，如下图范例图所示：

三、以"应用"为核心应该怎么做？

每个应用都有自己的职能，并依赖于各种与业务无直接关系的，相对独立的基础设施和组件，比如服务器资源，IP，域名，数据库，网络等等。所以，在产品的生命周期里面，除了应用本身这个实体以外，还有着各种基础组件实体，并且在应用上线后，还可能会不断的有新的组件产生，而新的组件不断产生，又会给后续的维护造成更大的困难。因此，以"应用"为核心就变得极其重要，通过应用模型和关系模型的梳理和建立，为后续持续交付、运维自动化奠定基础。

应用模型的梳理，其实就是上面范例中提到的电商网站，将一个产品拆分成多个模块，不同功能模块暴露自己的API供其他模块调用。拆分的工作更多是由产品架构师来把控，我们不展开讨论，重点看看运维层面关心的 应用管理模型的梳理。

应用管理模型：我们知道每个人都会有自己的各种属性，比如姓名，性别，职业，联系方式，家庭住址，×××号码等等，我们都知道每个人的名字并非唯一，同名同姓随处可见，而×××号码则是这个人唯一的标识。每个应用也有着自身的各种属性，比如应用名，功能，负责人，SVN地址，域名，部署架构，配置等等，而其中应用名就是该应用的唯一标识。

每个应用依赖的组件和基础设施大概可以分为两类：

资源层面：应用本身运行的载体，如物理服务器、容器、虚拟机，网络，以及对外提供服务的域名、IP等等。

基础组件：应用依赖的中间件，如nginx、tomcat、java等基础组件，以及数据库、消息队列、缓存、存储等等。

我们可以看到，这些基础设施/组件 本质上都是为上层的应用提供服务，抛开应用，这些基础设施/组件本身并没有单独存在的意义。

文中建议我们可以按这个思路去梳理应用 与 基础设施/组件之间的关联关系。例如，在用户中心（User）在申请数据库资源的时候，在数据库平台肯定也会要求业务方提供一个数据库平台范畴内全局唯一的一个标识，这里我假定这个字段叫做服务名。那么业务方在申请数据库资源的时候，就可以将数据库里面的服务名赋值为应用名User，又或者添加一个应用名的字段，通过外链的方式将数据库与应用关联起来。

同理，对于其他基础设施、基础组件也可以以类似的方法梳理。完成这一步之后，我们就会得到类似下面的一个以应用为核心的完整架构图，将应用、基础设施、服务、配置、运行载体等关联起来。

以上是我刚读完《进化：运维技术变革与实践探索》第一章的一些总结，并结合自身实际工作中遇到的一些问题和目前接触甲方单位的状态，展开的一些思考，篇幅比较长难免会有错漏，欢迎大家帮忙指正，也欢迎大家提出各自的观点，共同探讨这个话题，谢谢

由于是新书，想尽了各种办法，没有拿到电子版的share给各位了！内行同事很值得一读！

奉上一些书中大神的推荐吧！