大佬教程收集整理的这篇文章主要介绍了【云原生-白皮书】简章2:深入理解DevOps+微服务,大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。
在搞懂DevOps和微服务之前c;需要先搞懂什么是单体应用/单体架构。简单来说c;就跟在校的一些小项目一样c;项目的Demo写好了c;找一台服务器安装环境c;然后把jar包远程上服务器c;然后跑起来服务就可以了。这个时候进行简单的服务监控也不难c;如果项目出了问题c;查看一下运行日志c;就可以知道哪一步出问题了。如果懂一些脚本c;也可以写一些脚本分析日志c;解放双手监控服务器。这种单体架构就是采用瀑布流方式开发的c;服务的流程就是:设计 -> 开发 -> 测试 -> 部署 。
在还没有微服务和DevOps之前c;一个Web应用的上线c;一般都是将所有的功能都打包在一起c;也就是都在一个项目包里面c;然后将项目打包到一个服务器上跑起来就可以了c;那个时候的B/S应用架构就是单体架构c;结构图如下:
如果当用户访问量变大导致一台服务器无法支撑时c;就需要加服务器进行负载均衡c;这个时候架构的形式就是:单体B/S+负载均衡
用了一段时间负载均衡之后c;发现通过CDN手段c;把静态文件独立c;可以加速服务c;提升应用速度c;所以单体架构就进一步演变成了:B/S+前后端分离(CDN)
上面所说的架构都是单体应用c;只是某方面的部署形式进行了优化与改动c;所以最终都避免不了单体应用的普遍缺陷:
单体
1、代码量大c;应用启动时间较长。 2、测试周期长c;更改Bug需要对全部业务进行回归测试。 3、应用容错性差c;当某个程序出错后c;导致整个项目业务宕机。 4、伸缩性困难c;只能整个应用进行扩展c;浪费资源。 5、开发协作性困难c;项目人员都在维护一套代码c;协作周期长、难度大。
DevOps:Development和Operations的组合词c;是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程c;来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
随着上述说的单体架构时c;业务流量越来越大c;那么肯定几台服务器是不够用的c;这个时候就会加很多服务器机器c;也会加入Nignx、CDN、缓存、消息队列等技术栈c;同时开发人员也会变多c;这个时候就是 多人多机协同开发问题。
这个时候c;大多会将项目进行拆分c;每个人负责专注于开发一部分业务c;敏捷开发的核心理念就是既然无法充分了解超高业务流量下的用户的真实需求是怎样的c;就将一个大的目标不断拆解c;把它变成一个个可交付的小目标、小项目c;然后通过不断迭代c;以小步快跑的方式持续开发 。
此外c;这个时候项目是非常大的c;为保证项目质量c;测试环节不可减少c;为了加快速度增大开发效率c;测试的工作最好是和开发同步交替进行的c;需要将测试环节从后面注入到整个开发环节当中c;每次可交付的都是一个可用的功能集合c;对开发交付的内容进行持续验证。这样开发产品的可控性也更强c;可以阶段性的检验一下项目成果。
之前机器很少架构简单的时候c;开发就可以干运维的活c;就算加了几台服务器c;那也是脚本将 jar包 发布到这些机器上c;好像也挺简单c;但是会有两个人同时上线部署被覆盖的问题c;但这些都不是问题c;只要约定好错开时间进行上线部署就可以了。
但你如果是几千台服务器起步c;那就需要专门的运维人员进行维护项目了c;因为开发分工每个人都专注于自己的事情c;不会那么用心进行维护c;另一方面是运维的学习成本确实变高了c;开发人质量参差不齐c;如果服务器出问题那就不是小事。
但是这个时候也不是 DevOpsc;而是 Dev+Opsc;还没有融合在一起。这时 Ops 的主要职责就是:硬件维护、网络设备维护、DBA 、基础服务维护、数据监控等c;运维们擅长写各种部署c;监控脚本c;减少机械的重复工作c;开发模式变成了敏捷开发模式。
这个时候c;开发设计流程大致是这样。
到这里了c;还没有引入到DevOpsc;还要先再插入讲讲微服务c;才能更好的说明DevOps到底怎么理解。微服务(Microservices)是一种软件架构c;它是以专注于单一责任与功能的小型功能区块 (small Building Blocks) 为基础c;利用模块化的方式组合出复杂的大型应用程序c;各功能区块使用与语言无关 (Language-Independent/Language agnostic)的API集相互通信。
微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。
那么c;到底什么样的服务才能算是微服务? 1、单一职责的。一个微服务应该都是单一职责的c;这才是“微”的体现c;一个微服务解决一个业务问题(注意是一个业务问题而不是一个接口)。 2、面向服务的。将自己的业务能力封装并对外提供服务c;这是继承SOA的核心思想c;一个微服务本身也可能使用到其它微服务的能力。 (有点像SOA的演进)
微服务架构c;核心是为了解决应用微服务化之后的服务治理问题。
应用微服务化之后c;首先遇到的第一个问题就是服务发现问题c;一个微服务如何发现其他微服务呢?最简单的方式就是每个微服务里面配置其他微服务的地址c;但是当微服务数量众多的时候c;这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件:服务注册中心c;所有服务都注册到服务注册中心c;同时也可以从服务注册中心获取当前可用的服务清单:
解决服务发现问题后c;接着需要解决微服务分布式部署带来的第二个问题:服务配置管理的问题。当服务数量超过一定程度之后c;如果需要在每个服务里面分别维护每一个服务的配置文件c;运维人员估计要哭了。那么c;就需要用到微服务架构里面第二个重要的组件:配置中心c;微服务架构就变成下面这样了: 以上应用内部的服务治理c;当客户端或外部应用调用服务的时候怎么处理呢?服务A可能有多个节点c;服务A、服务B和服务C的服务地址都不同c;服务授权验证在哪里做?这时c;就需要使用到服务网关提供统一的服务入口c;最终形成典型微服务架构: 上面是一个典型的微服务架构c;当然微服务的服务治理还涉及很多内容c;比如:1、通过熔断、限流等机制保证高可用; 2、微服务之间调用的负载均衡; 3、分布式事务(2PC、3PC、TCC、LCN等); 4、服务调用链跟踪等等。
目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo(或者DubboX)c;Spring Cloud已经逐渐成为主流c;比较两个框架的优劣势的文章在网上有很多c;这里就不重复了c;选择什么框架还是按业务需求来吧c;业务框架决定技术框架。
Spring Cloud全家桶提供了各种各样的组件c;基本可以覆盖微服务的服务治理的方方面面c;以下列出了Spring Cloud一些常用组件:
了解完上述全部之后c;假设当原本是单体架构的公司发展到非常大规模的时候c;会有很多程序员、服务器等等c;所以一个项目里面c;什么语言、技术栈都会有c;Java、Go、Python肯定是数不胜数的c;所以c;这个时候需要协调技术栈c;并且项目后期肯定会变得非常大c;全部都兑到一个项目里c;最直接的后果就是项目变得很大c;上线项目启动时间变长c;一个BUG可能导致整个业务全线崩溃c;最终的后果就是项目变得越来越难以维护c;加一个改一个东西几乎搞不动c;而且还越来越难重构。
所以c;拆分解耦是最终的出路c;将项目拆成一个个小的服务单独部署c;以电商项目为例c;将整个项目拆分为用户服务、商品服务、订单服务c;积分服务、支付服务每个服务单独部署c;之间通过互相调用的方式来交互c;而且可以将一些基础服务例如上传图片c;发送短信等很多服务都需要的基础服务c;抽象到一个单独的整合服务c;也就是之前所谓的中台服务。
按照上述说的微服务架构进行开发DevOps的话c;运维需要做的上线工作c;主要就是将代码部署到对应的机器里面c;微服务有那么多的服务c;每个大点的公司几百个服务不算多c;而且还可能随时搞一个服务出来c;如果还按照原始的脚本部署方式c;可能最后连是哪个脚本都找不到。而且c;如果每个服务上线都需要运维来同意c;开发会非常难受c;需要天天找运维同意发布c;运维也会增加繁琐的工作量。
所以c;开始演化出远程部署一些机器c;专门用来管理代码c;进行上线工作c;由运维事先把上线的规则都给定义好了c;开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布c;自己上线呢c;能用代码自动完成的事情就绝不要手动解决c;这是每个开发人员都在想的东西。运维需要做的事情c;慢慢的都沉淀到了各个平台上面c;例如监控c;有专门的监控组件和可视化c;基础服务例如服务器c;CDNc;负载均衡等基础服务可以外包到云服务厂商c;日志也有专门的日志工具c;链路追踪也有专门的组件和可视化c;还有网关等c;渐渐的c;只要这些都配置好了c;开发也可以做运维的部分工作c;毕竟开发才是最了解代码的人c;哪里出了问题看看监控日志c;可以最快速度定位到问题c;于是DevOps开发模式诞生了c;开发也是运维。
早期的DevOpsc;大部分指的都是“开发运维一体化”。
而现在的DevOpsc;概念上已经扩大到端到端的概念了。
综上所示:DevOps 的三大支柱之中c;即人(People)、流程(Process)和平台(Platform)。
项目管理(PM):Jira。运营可以上去提问题c;可以看到各个问题的完整的工作流c;待解决未解决等; 代码管理:Gitlab。jenkins或者K8S都可以集成gitlabc;进行代码管理c;上线c;回滚等; 持续集成CI(ConTinuous Integration):gitlab ci。开发人员提交了新代码之后c;立刻进行构建、(单元)测试。根据测试结果c;我们可以确定新代码和原有代码能否正确地集成在一起。 持续交付CD(ConTinuous Delivery):gitlab cd。完成单元测试后c;可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题c;可以继续手动部署到生产环境中。 镜像仓库:VMware Harborc;私服nexus。 容器:Docker。 编排:K8S。 服务治理:Consul。 脚本语言:Python。 日志管理:Cat+Sentryc;还有种常用的是ELK。 系统监控:Prometheus。 负载均衡:Nginx。 网关:Kongc;zuul。 链路追踪:Zipkin。 产品和UI图:蓝湖。
参考文章: 1、知乎:什么是DevOps? 作者:小龙飞 2、知乎:微服务入门 作者:未知
以上是大佬教程为你收集整理的【云原生-白皮书】简章2:深入理解DevOps+微服务全部内容,希望文章能够帮你解决【云原生-白皮书】简章2:深入理解DevOps+微服务所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。