架构系列十七（云原生微服务架构体系实践思考）云原生和微服务，都是近几年后端研发小伙伴耳熟能详的的词，热门的有些不像话。但

云原生和微服务，都是近几年后端研发小伙伴耳熟能详的的词，热门的有些不像话。但还是相信很多小伙伴，并不是能很好的理解

那么，这篇文章，我想跟大家一起来探讨关于云原生与微服务架构体系实践的一些思考，抛砖引玉并期望在实际生产实践中带来一些帮助。

云原生，有两个层面的关注点，一个研发层面，再一个是运维层面。我们来看一个关于云原生比较贴切的定义，它是说

可见云原生工程化实践，涉及到的东西非常多，想要实践好并不是一件容易的事情！接下来，我们把每一个方面都展开来探讨。

关于微服务，与之对应的是单块应用。在微服务之前，我们叫做一个war包打天下，随着业务发展，不管是团队规模，还是应用体量都越来越多，于是带来了一些问题

最离谱的是，发布一个补丁，整个项目组小伙伴都得留下来随时待命，因为不知道发布过程中你负责的那一块会不会出现问题！

有问题，就需要解决问题。既然问题的根源是团队成员过多、应用体量过大，那就“拆”

这便是微服务，分而治之的解决问题之道。举个例子

当企业引入微服务工程化架构实践以后，一并引入了分布式系统固有的复杂性，因此有一些公共的关注点，是我们不得不去权衡及考量的

CI（Continuous Integration）持续集成，是指开发不同功能模块代码的团队成员之间，支持将代码频繁合并到一起，且相互之间不受到影响。

CD（Continuous Deployment）持续部署，是指借助平台工具实现自动化构建、测试、部署，最终实现产品的高质量交付。

下图是一个完整的CI/CD实践参考模型，可以看到从研发，到测试，到构建，到部署整个流程实现了自动化。

DevOps其实是离不开CI/CD的，它的目标是将研发运维一体化，最终形成 Code -> Build -> Test -> Release -> Operate -> Code 循环。Dev代表研发阶段；Ops代表运维阶段。

容器、云平台调度，业界当前应用最广泛的Docker+K8s组合，这个话题比较大，后面再通过其它文章我们进行专门探讨

游侠云AI普通

收藏 链接