什么是云原生的应用？

云原生应用的三个核心概念

在这里插入图片描述
链接：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考核指标不同，也导致他们对于软件的侧重点不同，这样造成了很大的隔阂。开发人员不清楚代码在生产环境如何运行，而运维人员也不清楚代码是如何构建出来的。线上环境出了问题只能反馈研发，然后运维人员还得给研发人员讲解一下生产环境如何部署，沟通成本非常高，部门之间合作解决问题导致故障的响应时间较长。