云原生和微服务，都是近几年后端研发小伙伴耳熟能详的的词，热门的有些不像话。但还是相信很多小伙伴，并不是能很好的理解
-
究竟什么是云原生？
-
微服务架构体系实践，需要考虑哪些关注点？
那么，这篇文章，我想跟大家一起来探讨关于云原生与微服务架构体系实践的一些思考，抛砖引玉并期望在实际生产实践中带来一些帮助。
1.什么是云原生
云原生，有两个层面的关注点，一个研发层面，再一个是运维层面。我们来看一个关于云原生比较贴切的定义，它是说
-
软件应用，基于微服务架构体系实践，并采用持续交付（CI/CD）和DevOps工程实践
-
运行时，以容器方式打包，且最终由运行于云基础设施上的平台（比如k8s）进行调度执行
从定义上抽象出相关的关键词
-
微服务
-
持续交付（CI/CD）
-
DevOps
-
容器化、云平台调度
可见云原生工程化实践，涉及到的东西非常多，想要实践好并不是一件容易的事情！接下来，我们把每一个方面都展开来探讨。
2.关于微服务
关于微服务，与之对应的是单块应用。在微服务之前，我们叫做一个war包打天下，随着业务发展，不管是团队规模，还是应用体量都越来越多，于是带来了一些问题
-
沟通协调成本变高
-
应用耦合严重
-
需求响应迟缓
-
构建部署效率低下
最离谱的是，发布一个补丁，整个项目组小伙伴都得留下来随时待命，因为不知道发布过程中你负责的那一块会不会出现问题！
有问题，就需要解决问题。既然问题的根源是团队成员过多、应用体量过大，那就“拆”
-
将一个大团队，拆成小团队
-
将一个大的单块应用，拆成一系列小的应用
这便是微服务，分而治之的解决问题之道。举个例子
微服务，组织架构变迁参考模型
-
传统职能型团队，它的特点是从人的角度，按照职能划分团队，比如说产品、研发、测试、运维等。当启动一个项目，我们其实是从不同的职能部门找人，组建成一个临时的项目团队。这个时候团队成员之间的沟通协作成本其实是很高的，大家习惯不一样，风格不一样，需要一个磨合的过程。
-
跨职能型团队，它的特点是从产品（或者项目）的角度来划分团队，比如说订单团队、商品团队、物流团队等。每个团队成员都是长期、全职服务某个产品线，团队成员之间的沟通协作会更加高效
微服务，应用架构变迁参考模型
-
单块应用，从业务边界参考，采用模块化分层架构，所有模块（用户、商品、订单）等，都将在一个war包内构建，部署到一个web服务器（tomcat），模块之间是进程内协作
-
微服务应用，从业务边界参考，采用服务化分层架构，将每个模块独立成一个服务，部署到独立的web服务器（tomcat），每个服务都是独立的进程，通过rpc跨进程方式协作
微服务公共关注点参考模型
当企业引入微服务工程化架构实践以后，一并引入了分布式系统固有的复杂性，因此有一些公共的关注点，是我们不得不去权衡及考量的
微服务，中台化架构参考模型
3.关于CI/CD
CI（Continuous Integration）持续集成，是指开发不同功能模块代码的团队成员之间，支持将代码频繁合并到一起，且相互之间不受到影响。
持续集成前置条件
-
自动化测试，研发团队要为每个新特性、代码改进、bug修复创建自动化测试用例
-
持续集成服务器（gitLab、jenkins），监控代码提交情况，针对每个提交执行自动化测试用例
持续集成收益
-
尽早获取回归测试结果反馈，避免将问题提交到生产环境中
-
发布编译更容易，合并之初即将问题进行了有效规避
-
测试成本降低，提升QA团队工作效率，不再需要花费大量时间成本在测试上面
CD（Continuous Deployment）持续部署，是指借助平台工具实现自动化构建、测试、部署，最终实现产品的高质量交付。
持续部署前置条件
-
研发团队深入理解测试理念，因为测试单元的健壮性，直接决定交付质量
-
文档与部署频率保持一致
持续部署收益
-
发布频率，交付更快，不需要停下来等待发布（不再强调发布日）
-
降低发布风险，通过小批量发布，发现问题可以更容易解决
-
提升客户满意度，客户可以每天看到持续改进提升（不再是每月、每个季度、每年）
CI/CD实践参考模型
下图是一个完整的CI/CD实践参考模型，可以看到从研发，到测试，到构建，到部署整个流程实现了自动化。
4.关于DevOps
DevOps其实是离不开CI/CD的，它的目标是将研发运维一体化，最终形成 Code -> Build -> Test -> Release -> Operate -> Code 循环。Dev代表研发阶段；Ops代表运维阶段。
DevOps参考模型
5.关于容器化、云平台调度
容器、云平台调度，业界当前应用最广泛的Docker+K8s组合，这个话题比较大，后面再通过其它文章我们进行专门探讨