基于微服务环境下的持续交付.docxVIP

基于微服务环境下的持续交付 任何事情都有两面性，在享受微服务便利的同时，也必需面对微服务交付所带来的挑战。经常听到大家聊到微服务架构时，聊得最多的是服务的拆分、实施微服务时接受的框架、技术选型、K8S、SpringCloud等等，所见到微服务架构项目，大多都没有真正做到“服务的独立部署”。这里的的“独立部署”并不只仅是简约的自动化部署，自动化部署相对简约，通过一些自动化工具、脚本等我们可以做到自动化部署。而微服务为什么不能简约的做到独立部署，不是“不能部署”而是“不敢部署”。 ● 微服务依靠关系错综简单，没有依靠的统一管理和依靠检查。 ●?微服务是虽然在物理上被拆分成多个小的服务，但从交付角度来看仍以一个全体对外供应服务。 ●?无统一的视图对开发、测试、生产环境的各个阶段进行管理。 ●?服务上线后无完备的手段对服务的监控、平安、容灾、扩缩容、流量爱护等。 因而微服务的实施不光是Devops的过程，更是一套生态环境、一套标准化开发、测试、生产上线的流程。 需要达成的目标 在持续交付中，我们需要构建一个标准交付流程，将开发、测试、运维、实施以及用户结合成一个全体。我们期望： ●?让软件构建、部署、测试和发布过程对全部人可见，促进合作。 ●?有效的反馈，以便在整个过程中，我们能够尽早地发觉并处理问题。 ●?通过预定义流程保障不同角色在本人关注的领域内正确、高效的完成任务。 ●?使团队能够通过一个完全自动化的过程在任意环境上部署和发布软件的任意版本。 怎样实施 整合公司现有基础设备平台（持续构建平台、容器云平台、监控平台、网关平台、微服务编程框架）结合微服务的特性，笼统定义了服务的整个生命周期， 从服务的定义、构建、依靠鉴权、部署、提测、发布、回收等各个阶段以流程的方式来规范开发、测试、运维等角色在各自领域的职责。 服务定义 在整个微服务的生命周期内，从微服务的定义开头，服务元数据会保存到分布式和版本化配置系统，为了规范在微服务环境中服务对外表述现将从以下方面来定义服务： ●?服务统一描述符 ●?服务依靠标识 ●?服务维护者 ●?服务授权级别 ●?服务证书、秘钥 ●?服务开发、测试、生产各环境地址 ●?服务监控大盘地址 服务初始化大事： ●?调用监控组件生成服务的监控大盘模板、服务健康拔测任务 ●?调用容器云平台生成服务证书、公钥、私钥、服务黑白名单 ●?调用网关平台绑定服务域名 服务构建 xx是微服务环境下的编程框架，不只仅只是高功能的Web容器，更重要的实现了服务管理的力量，供应了监控日志埋点、Metric、Trace等力量... 服务构建会基于编程框架的特性作以下动作： ●?扫描服务依靠列表 ●?扫描API列表（为统计和追踪API供应更精确的API管理，排解Restful格式下PathVariable干扰） ●?检查开发框架分区版本 ●?排解依靠Jar包的检查 服务构建以自定义插件扫描的方式输出服务依靠列表、API列表、检查开发框架分区版本、排解依靠Jar包检查等动作能最大限度的保障在微服务环境下 服务定义的完整性、依靠描述的精确?????性，提前避开部署运转时的兼容性。 服务依靠授权 在微服务环境下，我们供应了一套标准的基于TLS的访问把握策略。通过服务构建时扫描出的依靠服务列表，在服务部署之前需要先申请对被依靠服务的授权申请，被依靠服务(维护者)通过授权申请后 自动进入标准授权流程完成对依靠服务的授权操作。 服务部署 微服务环境中部署一个应用是很大的挑战，不能够像单体应用一样要求服务多副本部署，能正常启动就行了。在微服务环境里由于一个应用由多个微小的服务组成并对外供应统一的服务，服务之间的相互依靠关系、服务之间的访问把握权限、服务对资源的消耗、服务健康检查机制、服务上下游拔测手段、服务之间流量管理等问题将是我们不得不面对和处理的。 我们通过标准化流程管理组件来观看和规范服务部署、资源回收、线上运维等流程，标准化流程管理组件会将各大事笼统成“元语”，将“元语”下发到各组件执行并依据执行情况来串联起整个流程。依据开发、测试、生产运维环境需求我们制定了如下流程： ●?部署流程 ●?蓝绿部署流程 ●?服务授权流程 ●?灰度流量调整流程 ●?回收流程 ●?蓝绿回收流程 ●?强制回收流程 这里我们将以部署流程来重点讲解，其次要节点包括：资源规划、前置检查、资源申请、服务部署、功能验证、服务准入等操作。 资源规划 将一个应用拆分为多个微服务，每一个微服务单独部署，服务数量会成倍添加，因而有必要在部署时对消耗的资源进行规划，否则会形成资源的极大铺张，添加公司运营成本。 在资源规划时不能简约粗爆的限制CPU、内存、磁盘、网络带宽等，我们应当依据服务的特性把服务划分为不同的类型，比如：IO密集型、CPU密集型等，这样提交给容器云平台（资源调度）