微服务架构设计与治理服务内容说明

1.服务概述

1.1 服务说明

随着云计算的不断发展、普及，越来越多的企业不断加深了对云的了解，并积极的落地云化改造，趋势已经从上云逐渐转变为用好云，而标志着云计算技术红利的云原生技术，则渐渐的成为业界标准以及未来方向。作为云原生技术的重要实现场景，微服务化也是企业进行云原生技术转型的关键步骤。阿里云作为 CNCF 的顶级成员与贡献者，在云原生、微服务化方面进行了深入的投入，并为客户提供云原生架构咨询服务。通过实现微服务改造、持续交付等云原生领域的关键技术，配合阿里云完整的云原生产品布局，与客户一起打造更灵活、更现代、更标准的云原生应用，为更高效、更快速的业务发展提供助力。

广义上来说，云原生一般指代四种核心技术：容器化、微服务、DevOps 与持续交付，随着云计算的发展，这四种概念可以分别扩展，容器化特指应用程序的运行环境，达到统一的管理和编排；微服务则强调应用程序架构，足够分布式、解耦并高内聚，是面向弹性的无状态式聚合；DevOps 强调自动化与可观测性，通过该领域内流行的方法论、工具达到资源利用、性能监控、服务治理等能力；而持续交付则代表应用程序响应业务的能力，不论是灵活性还是健壮性，以及常说的弹性。

微服务架构设计与治理服务主要围绕企业微服务化的技术需求提供支持，主要包括云原生架构设计、持续交付、微服务改造、微服务治理等，这些会根据具体项目与甲方需求进行调整。

2.服务范围

以下服务范围分3个类别：微服务架构设计服务，微服务架构治理服务，微服务架构实施支持服务，不同客户类型按照不同的需求进行交付。

2.1 微服务架构设计服务

微服务架构设计服务主要分为基础版和标准版，具体内容如下。

2.1.1 基础版服务范围

基础版服务主要内容如下：

• 基础设施调研

• 业务现状和应用系统调研

• 云上基础架构设计

• 微服务技术选型及标准方案设计

• 以Demo形式对客户的某一业务场景的某一模块进行方案验证（验证的Demo中关联微服务不超过3个，每个微服务实现不超过2个接口，只支持单语言）

2.1.2 标准版服务范围

标准版服务在基础版的基础上增加了以下两项服务：

• 容器化：基于阿里云ACK搭建k8s集群

• CICD：基于云效或开源gitlab，jenkins等方案搭建自动化可持续交付基础设施

• 以Demo形式完成以上两项服务的验证

2.2 微服务架构治理服务

架构治理服务同样分为基础版和标准版，具体内容如下：

2.2.1 基础版服务范围

调研和评估客户1个核心业务系统并出具治理方案，并帮助客户快速落地方案并上线。

2.2.2 标准版服务范围

调研和评估客户1个核心业务系统并出具治理方案，并帮助客户快速落地方案并上线；提升客户业务系统的发布效率和全链路可观测能力。

2.3 微服务架构实施支持服务

按照微服务架构设计以及治理服务的方案内容，为客户落地实施过程中提供技术支持。

以下内容不在服务范围内：

• 不参与到客户实际的业务代码修改，只基于方案提供技术支持。

• 支持的技术范围仅限基于阿里云标准产品的方案及实施，不负责客户云下，或者云上自建的第三方服务的技术支持及问题排查工作。

• 实施技术支持一般按照项目周期约定好时间范围，不提供无限期的技术支持工作。

• 实施技术支持过程中，不为整体的实施进度负责，实施进度依赖于客户，阿里云仅提供技术支持&问题排查工作。

3.前提条件

• 甲方应提前至少15个工作日申请该服务，以便于阿里云评估甲方业务目标及时间计划可行，确认是否承接该服务申请。

• 甲方应及时向乙方提供所有需要的合理的文档、信息、数据、图表以及必要的系统权限、远程访问通道以使乙方可以提供服务。且所有这些资料将受到本协议项下的保密条款的约束。甲方同意向乙方已披露的或将要披露的所有信息是真实、准确并且不会产生误导。

• 本项目提供的是微服务架构咨询服务，乙方的办公地点不受项目约束，服务的提供方式主要以：电话、钉钉、邮件等方式。

• 本项目交付过程中，实施主体为甲方，乙方主要提供方案设计以及实施过程中的问题处理，具体的应用部署和测试动作需要由甲方进行。

• 双方在项目实施期间采用双方同意的通讯方式，由双方的项目经理负责传递本项目所需的书面信息，可选择的通讯方式包括：钉钉、互联网、电子邮件等。

• 所有项目交付物为中文（简体），工作语言为中文。所有交付作品采用Microsoft Office（包括PowerPoint，Word，Excel，Visio）格式，并以电子拷贝方式提交。

• 甲方与乙方应须按双方事先达成一致的工作计划、人员资源计划与书面确定的工作起止日期投入项目工作。如遇到甲方相关业务系统迭代延期上线，相关项目进度将会产生顺延，乙方对此不承担责任。

• 任何一方均不对本项目下的特殊、附带、或间接损害或后果性经济损害（包括利润或节省金额损失）负责，即便该方已被告知该等损害赔偿的可能性。

• 客户作为运维主体，需进行自身业务相关的运维工作。

4.分工边界

4.1.1 客户与阿里云

• 双方商定并确认具体业务目标及范围。

• 合同签订完毕，完成付费。

4.1.2 各阶段工作的双方职责

根据项目计划的阶段任务工作，双方在不同阶段需要承担不同的分工以顺利推进项目进行。

5.服务SLA

• 提供微服务架构设计及治理专家服务。

• 在服务期间内向客户提供服务包内的相关履约内容的技术咨询和培训指导。

• 按对应服务包提供对应的交付物。详见《7.1验收清单》。

6.服务流程

申请时间限制：客户须至少在服务开始前15天提出服务购买申请。

服务流程介绍：

7.验收标准

7.1 验收分项清单

微服务架构设计服务验收清单

微服务架构治理服务验收清单

7.2 验收标准

1、乙方进行为甲方提供服务包内的技术咨询和指导，协助甲方进行微服务架构设计并提升微服务架构稳定性，并将整个过程中技术方案、问题等记录在文档内，因此文档类交付成果应着重文档实质内容的验收，确认乙方提交内容符合甲方需求。

2、若甲方业务流程要求在乙方提交交付成果前需进行各类内部评审，甲方应在约定的验收时点前推动并及时完成其内部所需评审和汇报。

3、文档内容经过评审会，若需要修改，乙方修改后提请甲方进行验收，由甲方指定的代表进签署，如无异议，客户应在5个工作日内进行线上或书面确认（包括但不限于电子邮件），验收清单详见《7.1验收清单》。

• 微服务架构设计基础版和标准版验收标准：

  • 方案设计达到客户要求，经过验收确认，具体方案见《7.1 验收分项清单》

• 微服务架构治理基础版和标准版验收标准：

  • 方案设计达到客户要求，经过验收确认，具体方案见《7.1 验收分项清单》

• 微服务架构实施支持服务验收标准：

  • 按照方案设计提供的实施支持服务，结果满足客户预期，具体方案见《7.1 验收分项清单》

7.3 验收计划

根据《7.1验收分项清单》所列示各阶段的交付内容与交付物，本项目将按照以下验收计划进行项目验收，甲方同意根据此验收计划对乙方的交付物进行验收。

8.完成标志

客户验收完成。