云原生应用的三个核心概念
链接：https://pan.baidu.com/s/10ocbDCGsdS3i7hEzvUlatA?pwd=m9nr
提取码：m9nr
–来自百度网盘超级会员V5的分享
脑图大家可以下载使用并补充
微服务
什么是单体应用？
传统的单体应用架构都是三层模式：表示层（用户可见的交互页面，如Web页面）、业务层（核心业务逻辑处理）和数据访问层（将应用数据保存到后端存储，如数据库、磁盘等）。然后将它们打包编译后放到一个Web容器（如Tomcat、Jetty）里面运行，如图所示。
这种单体架构在面对小规模、简单的业务场景应用时得心应手，易于开发、测试和部署。
单体应用的问题
随着业务越来越复杂，用户数（并发数）不断增多，可维护性和可扩展性越来越低。
惯用的解决方案是
- 前端通过负载均衡分流
- 后端分库分表，增加缓存等。
这些调整可以在一定范围内增加并发，但系统仍然是单体，仍然存在很多问题
（1）维护性差，业务是耦合在一个项目中，任何代码的变动都需要重新上线整个项目。试想几十人维护十几万行代码的场景，系统的任何变化都需要构建整个系统。而且需要开发人员非常熟悉整个系统的架构，否则很容易导致出现“修复一个bug，引发两个bug”的问题。一个典型的案例是Oracle的2500万行C代码，每次修复一个bug需要开发人员花两周时间理解bug，然后修复bug后提交测试，大约花20～30个小时测试bug是否修复。
（2）扩展性差，单体的应用始终无法避免的问题是数据库的性能瓶颈，并且在资源扩容的时候很难做到精准控制，比如将一个计算密集型的业务和一个I/O密集型的业务放到一个单体服务中，那么部署该服务的机器就必须同时满足这两点需求，这会造成资源浪费。
（3）交付能力差，尤其在互联网企业，具备较强的交付能力是非常重要的。市场和需求不断变化，需要产品能随之变动。单体应用随着功能不断增多，多个团队需要严密配合，每个开发代码提交的窗口就需要严格被限制，这极大地降低了开发效率，并且单体应用的构建时间随着代码的增多也随之增加。
什么是微服务？
将一个单体服务按照业务逻辑拆解成独立运行的微小服务，服务之间使用轻量级的机制通信
微服务的特点
●业务划分
以业务边界确定服务边界，构建出若干个小而自治的微服务。由多个团队维护一个耦合性很高的系统是非常困难的。微服务可以很好地将架构与组织结构匹配。一个微服务由一个小团队独立完成，这也更符合康威定律。比如可以将产品、合同、订单拆分成三个微服务。
一个微服务就是一个SRP（Single Responsibility Principle**，单一职责）的独立个体**。根据业务边界来确定服务边界，避免与其他服务共用资源。
●轻量级通信
服务之间通过**轻量级的通信协议（**如HTTP、GRPC）互相通信，而无须关系具体的技术栈
一个Go语言的项目可以通过HTTP协议访问Java项目，只需要大家遵循共同的通信协议即可。
●独立部署
每一个服务都可以独立开发、构建、测试和部署。每一个服务只需要连接自己数据库，而不用担心与别的服务之间的耦合，部署更加简单。
●可复用可组合
在微服务的架构下，服务不再属于某一应用，而是可以为不同的应用提供相应的能力，这体现了微服务的最大价值，重用微服务避免了重新编写代码，大大降低了开发成本。在一个企业中，随着公共的微服务，如邮件、短信、OA等不断增多，每个新的项目只需要编写自己的业务逻辑，通过服务调用的方式接入各种外部系统。
自动发现与注册机制
微服务将应用拆分后势必导致服务个数的暴增，传统的“写死”服务调用地址的方式已经不适用了，必须有一套服务自动发现与注册机制。
如图所示，服务端首先将自己的访问地址注册到注册中心，当客户端通过Proxy访问服务端时，会先通过本地代理，本地代理通过注册中心获取服务端地址，并通过负载均衡策略，将请求转发到服务端，完成服务之间的调用。调用的方式包括HTTP、RPC等。
网关的功能
（1）协议转化，将SOAP转化为Rest，将xml转化为json等；
（2）认证鉴权，统一拦截请求，校验权限；
（3）日志审计，记录每个请求的访问日志；
（4）流量管控，控制请求的并发数，防止恶意攻击。
在生产环境中，通常微服务网关会部署多套，分别是内部网关、无线网关、第三方网关等多个网关，并且每个网关都是高可用部署，防止单台故障造成整个服务不可用。
微服务注意事项
应用从单体到微服务，对底层框架的技术要求更高，分布式系统排查问题的难度也会加大，
所以，应用是否需要微服务还得根据实际的生产场景判断，如果只是几个人维护的一个简单应用，是没有必要折腾微服务的，毕竟“适合自己的才是最好的”。
DevOps
随着软件发布迭代频次越来越高，传统“瀑布式”（开发—测试—发布）软件开发流程已经不能满足需求，即传统的开发人员只负责代码开发，而运维人员只负责运行环境的维护，并且研发通常关注功能开发，总是想尽快上线新业务，不断满足新的客户需求，而运维总是想使环境稳定，少出故障，“稳定压倒一切”。任何差错都有可能对生产环境中的用户造成直接影响。开发人员和运维人员的KPI考核指标不同，也导致他们对于软件的侧重点不同，这样造成了很大的隔阂。开发人员不清楚代码在生产环境如何运行，而运维人员也不清楚代码是如何构建出来的。线上环境出了问题只能反馈研发，然后运维人员还得给研发人员讲解一下生产环境如何部署，沟通成本非常高，部门之间合作解决问题导致故障的响应时间较长。
DevOps本质
DevOps本质上是一个开发人员干完所有的活，从代码开发到服务上线，DevOps最先都是一些硅谷的初创公司的大牛们为了节省成本，艺高人胆大，自己干完了所有事，后来发现这样办事的效率很高，然后各个互联网公司也都争相效仿，才慢慢普及的。
DevOps工具链
DevOps是一种方法论，或者是一种软件开发文化。它的具体实现方式和实现工具有很多，按照开发流程，这些工具主要分为以下几个大类。
代码库：Gitlab、GitHub、gogs、svn、BitBucket；
自动构建：Ant、Maven、Gradle；
CI/CD: Jenkins、Travis CI、Fabric、Gitlab CI、buildbot; 、argocd
配置管理：puppet、chef、saltstack、ansible；
部署平台：Kubernetes、OpenShift、Mesos
DevOps 领导者
AWS和Netflix
容器化
应用迁移到容器的大前提
将应用迁移到容器最主要的改造是将应用变成“无状态”
什么是“状态”？
状态指的是应用里面的数据状态，具体来说，就是应用的会话、用户数据、中间变量、文件等。
“无状态”就是将应用的状态信息从应用中剥离出去，保存到对应的存储中间件中，
- 通过Redis保存会话和Token，
- 通过MySQL保存关系型数据，通过对象存储保存图片。
微服务和容器的关系
容器的使用方式是允许随意重启，当应用出现问题时，可以通过重启解决。将应用变成无状态，就是为了解决重启带来的数据丢失和不一致问题。
这需要对之前单体的有状态的应用进行微服务改造，容器化和微服务是相辅相成的。
只有通过微服务才能将复杂的业务逻辑拆分、去状态，独立管理。而微服务最好的载体便是容器，容器对应用的要求也是无状态，容器的快速启停、快速部署正适合微服务快速迭代的要求。
CNCF
CNCF维护的项包括了基础云设施、配置管理、运行时、编排，以及应用管理等多方面全栈项目
