从程序员到大型分布式架构师，自己到底位于哪里（二）

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

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

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

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

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

从程序员到大型分布式架构师，自己到底位于哪里（一）

这一篇接着讲述……

1.分布式服务治理方案

1.1.简述几个名词

什么是服务治理？

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

分布式架构是什么？

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

应用上云和分布式架构

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

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

1.2.技术实现方案

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

两者最本质的区别：

RESTful 强调一切都看作资源，对资源进行操作；

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

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

技术实现方案：SpringCloud

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

技术实现方案：Dubbo + Zookeeper

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

链路追踪系统

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

监控告警系统

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

日志分析系统

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

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

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

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

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

关键技术

kubernetes（自动化运维平台）–平台
Jenkins Pipeline（流水线） — 流水线
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年都出书了也不是什么新鲜事物，过度设计还不如层次分明更利于开发维护。

阅读上一篇：从程序员到大型分布式架构师，自己到底位于哪里（一）

转载指明出处！！！