AI智能
改变未来

从​程序员到大型分布式架构师,自己到底位于哪里(二)

写这篇文章为了更清楚自己技术能力,同时分享给大伙,看看自己技术水平位于哪里。

个人能力有限,基于我所理解的知识来讲解一下:从程序员到大型分布式架构师,我们自己到底位于哪里。

描述不当之处还请各路大佬点明,老弟也好更上一层楼!!!

本人就以之前画的微服务系统架构图来逐一讲解。

上一篇讲述了:Java程序员刻苦修炼锻造基础

从程序员到大型分布式架构师,自己到底位于哪里(一)

这一篇接着讲述……

1.分布式服务治理方案

1.1.简述几个名词

什么是服务治理

反过来读一下:治理服务。分布式服务治理方案就是通过什么方案来治理分布式的服务。强调的还是“服务”,所以治理的前提是有错综复杂的业务服务,才需要整这么一套方案去解决这问题。

分布式架构是什么?

一整套的分布式架构的搭建就像建造一个自动化生产车间。新增的“业务系统N”部署到这个大家庭便会拥有架构中一整套的能力(服务治理能力、自动化能力、大数据能力等等)。

应用上云和分布式架构

在这几年经常会听到或谈到“上云”这个词语,“应用上云”和“分布式架构”这两者乍眼一看两者没啥关系,其实关系大得很。就以阿里云为例:你将新增的“业务系统N”部署到阿里云,需要什么能力的服务是不是用钱买就行啦?或者直接搞个“行业解决方案”。这种第三方云又称为公有云;有“公”就有“私”,私有云就是企业自个独有的云;两者一混就变成了混合云。云可以看作是完整的一套分布式架构+基础设施。怎么上云,先申请资源(软件资源、硬件资源和网络资源),再将业务服务部署到这分布式架构中,从而实现所有资源可插拔和服务的统一管理,这就是为什么现在都喜欢搞“上云”的原因之一。

本文是为读者做定位和后续学习有目标,在此不展开太多。

1.2.技术实现方案

常用的两种分布式服务治理方案:RESTful 和 RPC 分布式服务治理方案。

两者最本质的区别

RESTful 强调一切都看作资源,对资源进行操作;

RPC 是远程过程调用,强调的是客户端和服务端的交互。

RESTful分布式服务治理技术方案

技术实现方案:SpringCloud

RPC分布式服务治理技术方案

技术实现方案:Dubbo + Zookeeper

两种方案中都没有提供一套完整的服务治理技术实现,还需加入链路追踪技术、监控告警系统、日志分析系统等​。

链路追踪系统

在分布式环境中一个业务处理涉及多个服务间的调用,传统方式通过系统日志很难做到故障问题快速定位,而通过链路追踪可以实现故障快速定位。链路追踪系统除了故障快速定位功能,还有可视化(如性能指标)、依赖优化(梳理服务依赖关系以及优化)、数据分析(如用户的行为路径,汇总分析应用在很多业务场景)。

监控告警系统

​一般监控有流量监控、异常监控、资源使用率、请求延迟等。当监控的数据超过指定范围,就会通过邮件或电话进行告警通知,也可以在可视化平台查看监控数据,收到告警通知的人员便会去处理相应问题。

日志分析系统

日志分析是运维工程师解决系统故障,发现问题的主要手段。

服务治理技术包含在红色框中

2.DevOps(开发运维一体化)

为了高可用,将业务服务集群化是一件很正常的事,但每次都要改动都要部署到不同的几台服务器,做着重复的工作而且很有可能出错,一次改动一天部署完成算是很顺利的事了。是不是很想要有自动化部署这种东西呢?其实自动化在很多行业早就有了,现在很多行业都已迈入智能化时代了。

DevOps开发运维一体化并不是让开发去做运维,而是使开发和运维通过一些机制有机结合、高效统一,成为一个整体,从而消除开发团队和运维团队之间的隔阂,有效提升应用服务的研发和运维运营效率。

关键技术

  1. kubernetes(自动化运维平台)–平台

  2. Jenkins Pipeline(流水线) — 流水线

  3. docker(容器) –包裹

主要涉及两种角色:开发人员(developer)和 运维人员(Operation)

&

两者的隔阂其实是通过容器化部署方式来解决,运维人员只需要知道容器镜像怎么部署即可,不需要知道其中的细节。

持续集成(CI):从程序员提交代码到自动打包生成docker镜像,并部署到指定测试环境

持续交付和部署(CD):测试通过后,运维人员将docker镜像部署到生成环境

整个流程都可以在k8s平台中看到,并且支持项目部署的回滚操作,更多细节就不一一展开。

3.大数据接入

经常会听到大数据“杀熟”,同一个平台杀熟就算了,跨各大平台杀熟就很让人恼火。比如:我在淘宝或京东搜索了下运动器材,然后在各种平台都会收到各式各样的运动器材推荐。这种智能推送又被称为智障推送,比如:我看了某种商品的某种规格后,再次搜索商品就都是这种规格,其实这不是我想要的结果。大数据是把双刃剑,搞得好智能,搞不好智障,甚至触犯法律条款。

分点简述

  • 大数据平台:Hadoop

  • 数据来源:数据库,缓存中间件,文件存储,数据仓库等等。

  • 数据采集方式:实时采集 和 离线采集

  • 数据采集技术:kafka,flume,sqoop 等等,不同的数据来源使用不同的采集中间件技术

  • 数据存储技术:Hbase,HDFS 等等

  • 数据处理方式:实时处理 和 离线批量处理,分别对应不同的技术栈

  • 数据服务:提供服务实现价值,如:精准营销,浏览,分析检索,下载等等

  • 平台管理技术:Apache Ambari(供应、管理、监控等)和Zookeeper(平台配置与调度)

4.其他

4.1.内网DNS

优点:方便记忆和服务迁移IP更换只需要修改DNS即可;

缺点:DNS服务可能成为性能瓶颈和影响可用性。

4.2.网络区域和出入网控制

业务服务都部署在内网环境,主要原因是安全问题和IP资源问题。

内网环境还可以拆分成多个区域:DMZ区、业务区。DMZ 称为隔离区,对外对内都有防火墙隔离,隔离外网和内网的一个区域。常用于部署以外网对接的系统服务。内网业务区,顾名思义是部署业务相关的服务。

统一入网:服务部署在内网环境,每个对外提供服务的系统都需要有个入口,为了网络安全和更好管理便有了统一入网,需要提供互联网服务的系统申请入网资源即可。

统一出网:对于内网系统需要访问互联网资源时,则通过统一出网来控制。

4.3.安全技术

网络安全

  • 内网部署,内网专有网络

  • 统一出入网

  • 应用防火墙WAF:免受各种常见攻击(XSS 攻击、注入攻击、DDOS攻击等)

  • 使用HTTPS

  • 运维人员必须通过内网堡垒机来访问内网服务器

等等

编码安全

  • 浏览器Cookie加密与过期

  • 服务间通讯加密

  • 登录防爆力图像验证码等的多种验证方式(如:邮件或短信验证码的一次一密)

  • 数据防爬虫机器人验证

  • 重要信息数据脱敏(如:手机号,姓名,证件号,卡号等)

等等

服务器安全

  • 通过渗透测试确认数据库、应用等安全性,常用的技术:nmap、burp suite、sqlmap等。

  • 容器部署的安全性

  • 常用中间件安全性

等等多种安全技术,从代码到整个平台所涉及之处都要考虑安全问题。

4.6.其他唠嗑

随着业务的发展,会持续出现技术问题,业务问题,开发问题,运维问题,业务响应速度等等。避免重复造轮子,需要对通用能力抽离;不同业务不断发展形成不同的软件平台,平台间职能边界划分问题和数据孤岛问题,需要引入领域驱动设计思想和中台思想来解决相应问题,但项目一开始还是建议使用面向对象软件设计方法,不要看到到处说DDD就凑热闹,领域驱动设计在2014年都出书了也不是什么新鲜事物,过度设计还不如层次分明更利于开发维护。

阅读上一篇:从程序员到大型分布式架构师,自己到底位于哪里(一)

转载指明出处!!!

赞(0) 打赏
未经允许不得转载:爱站程序员基地 » 从​程序员到大型分布式架构师,自己到底位于哪里(二)