微服务井喷时代，我们如何规模化运维？

随着云原生技术发展及相关技术被越来越多运用到公司生产实践当中，有两种不可逆转的趋势：

1、微服务数量越来越多。原来巨型单体服务不断被拆解成一个个微服务，在方便功能复用及高效迭代的同时，也给运维带来了不少挑战：

• 成本问题：服务及基础资源依赖的生命周期该如何运转？如何防止孤儿资源存在，防止资源浪费？如何提升资源利用率？

• 效率问题：单元化服务如何快速高效部署？服务梳理及批量搭建

• 责任归属：面对数量级倍增的服务及资源，如何找到责任人及归属团队？(有问题如何找到合适的人处理及跟进？成本如何归属到合适的团队？)

备注：这里主要关注服务及服务依赖的基础设施管理及运维，不关注上下游依赖管理，上下游依赖可以通过服务治理（依赖拓扑）等解决。      

2、服务越来越复杂，依赖的基础设施更多样化（如自建机房、云机房、混合机房等），依赖的中间件越来越多（如企业内部自建系统、各大云厂商服务等），用户是否需要感知这些基础设施的差异？

• 如果感知，用户的使用成本会增加，规范标准如何去约束？

• 如果不感知，则这些底层差异如何屏蔽？ 

解决思路

要解决如上两个问题， 首先要找到如上问题的根因是啥？

问题1：信息割裂、冗余及缺乏信息更新

举例1：

当前滴滴内部对于一个服务主要关注它的计算资源（弹性云资源）及对应服务树节点的观测、报警等运维相关属性，如上属性都是通过服务树节点ns关联起来，对于存储类资源并没有相应的关联关系元信息（只存在代码配置中）。一个服务能整体运转起来的完整依赖没有一个清晰的视角，如果想要了解完整依赖，需要SRE去梳理相关运维属性，服务负责人去查看代码梳理出来底层中间件依赖。

解法：将计算资源、存储资源及一些偏运维配置按照服务维度做整体抽象及关联，这样使得服务有整体的视角，同时相对单个服务，整体才能更好的管理生命周期，避免出现孤儿资源，防止资源浪费。见图应用示例，可以看清一个应用所依赖的所有IaaS资源及PaaS资源。

同时通过观测服务整体的资源使用情况，可及时发现资源利用率低下或资源不足的问题，并采取响应的措施进行优化。       

应用组合抽象

应用示例