从程序员到大型分布式架构师，自己到底位于哪里（二）
写这篇文章为了更清楚自己技术能力，同时分享给大伙，看看自己技术水平位于哪里。
个人能力有限，基于我所理解的知识来讲解一下：从程序员到大型分布式架构师，我们自己到底位于哪里。
描述不当之处还请各路大佬点明，老弟也好更上一层楼！！！
本人就以之前画的微服务系统架构图来逐一讲解。
上一篇讲述了：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年都出书了也不是什么新鲜事物，过度设计还不如层次分明更利于开发维护。
阅读上一篇：从程序员到大型分布式架构师，自己到底位于哪里（一）
转载指明出处！！！