架构

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 背景 Tablestore 启发自 Google 的 Bigtable 论文，从2009年开始，在阿里云的飞天团队内，开始萌发。经过10年的锤炼，如今在集团内，云上积累了各式各样的客户和场景。这篇文章我们就来介绍下 Tablestore 大数据场景下的架构和用户场景案例。看看自研的分布式存储平台如何通过贴身理解客户场景，带来大数据架构的简化和升级，并助力业务方最终快速落地他们的需求。 大数据系统建设中的痛 数据的产生是多式多样，我们根据需求会选择不同的存储产品来存放这些数据，例如订单数据，用户信息数据我们会选用一款 OLTP 数据库，日志数据会选择 SLS 日志服务，或者自建 ELK 的方案。又有一些数据我们希望做实时的 计算，并且在 ETL 后在进行长期存储，这时会把数据双写到 Kafka，利用 Kafka 流式对接计算引擎的能力实现上面的需求。一些非结构化数据又会使用 HDFS/OSS 来进行长期存储。这些数据从存储到可以给计算引擎分析需要经过很长的链路。例如如果你选用了一款 OLTP 数据库，你希望进行实时计算或者定期批量计算。考虑到避免影响 TP 在线业务，通常我们会把数据实时或者定期投递出来，进入 Kafka/AP 数据库再分别实现实时计算和批计算。投递的过程可能会涉及到很多模块，例如 DTS

https://mp.weixin.qq.com/s/UIZL78m105btP2HWFmQmlw 来源： CSDN 作者： supergreensea 链接： https://blog.csdn.net/supergreensea/article/details/103605898

一、 什么是 SpringCloud 什么是 SpringCloud：是一个服务治理平台，提供了一些服务框架。包含了：服务注册与发现、配置中心、消息中心 、负载均衡、数据监控等等。 1 概念定义 Spring Cloud 是一个微服务框架，相比 Dubbo 等 RPC 框架, Spring Cloud 提 供的全套的分布式系统解决方案 。 Spring Cloud 对微服务基础框架 Netflix 的多个开源组件进行了封装，同时又实现了和云端平台以及和 Spring Boot 开发框架的集成。 Spring Cloud 为微服务架构开发涉及的 配置管理，服务治理，熔断机制，智能路由，微代理，控制总线，一次性 token，全局一致性锁，leader 选举，分布式 session，集群状态 管理等操作提供了一种简单的开发方式。 Spring Cloud 为开发者提供了快速构建 分布式系统的工具 ，开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。 2 Spring Cloud 的项目的位置 Sping Cloud 是 Spring 的一个顶级项目与 Spring Boot、Spring Data 位于同一位置。 3 Spring Cloud 的子项目 Spring Cloud 包含了很多子项目，如： 3.1Spring Cloud Config：配置管理工具

自从5月8号写完架构设计三部曲的第一部 如何写架构设计说明书 ，到现在快20多天了，这段时间主要准备了下系统分析师的考试，当然还有各种工作上的杂事，于是也就拖到现在写第二部如何评审架构设计说明书。当然这个是从评审的角度来看的，其实从编制架构设计说明书的角度来看，也可以阐述具体如何编写架构设计说明书，就像高考作文一样，评审总是有些采分点的嘛，那么对于编制架构设计说明书来说，哪些是我们应该准备的采分点呢？我们在编制的过程中需要重点注意哪些章节的哪些内容呢？这就是我接下来想和大家分享的。 根据第一部文章我们知道一篇架构设计说明书大致章节应该是这样的： 文档概述：包含项目背景、项目目标、文档版本信息、目标读者、参考文档、名词解释之类的一般文档都会有的章节； 整体架构：主要从整个IT层描述系统所处的位置，与周边关联系统之间的调用关系； 逻辑架构：系统内部功能模块的划分以及各模块功能介绍、相互之间的关系表述； 接口设计：包括系统间的接口设计以及内部功能模块之间的接口设计； 数据架构：本系统与上下游系统间的数据流关系，以及本系统关键数据表设计、数据管理策略等； 技术架构：实施此架构需要用到哪些技术能力，有哪些复用能力及风险； 部署架构：系统如何部署，网络拓扑上有何要求，对硬件服务器有何要求，需要几台，是否需要优化服务器参数； 非功能性设计：性能、高可用、可扩展性、可维护、安全性、可移植性等。

讲师介绍 严锁鹏， 奇虎360大数据架构运维专家，具有10年基础架构与大数据开发经验。2013年加入360商业化团队，负责消息中间件开发与运维，同时涉及大数据架构、微服务架构、实时计算平台、机器学习平台、监控系统等基础设施建设，致力于为商业化团队提供稳定高效的基础服务。 大家好，我是来自360商业化的严锁鹏，今天我会向大家分享如下内容： 分享概要 1、消息队列选型 2、Kafka在360商业化的现状 3、Kafka client框架 4、数据高可用 5、负载均衡 6、鉴授权与ACL方案 7、Quota机制 8、跨IDC的数据同步 9、监控告警 10、线上问题及解决方案 一、消息队列选型 当时主要考虑以下几个维度：社区活跃度，客户端支持，吞吐量。对比几个系统下来，觉得Kafka比较符合我们的要求。现在有一个新的开源系统pulsar，我觉得也可以尝试一下。 1、Kafka设计上的亮点 Kafka性能和吞吐都很高，通过sendfile和pagecache来实现zero copy机制，顺序读写的特性使得用普通磁盘就可以做到很大的吞吐，相对来说性价比比较高。 Kafka通过replica和isr机制来保证数据的高可用。 Kafka集群有两个管理角色：controller主要是做集群的管理；coordinator主要做业务级别的管理。这两种角色都由Kafka里面的某个broker来担任

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 相同点： 1. Tomcat和Jetty都是一种Servlet引擎，他们都支持标准的servlet规范和JavaEE的规范。 不同点： 1. 架构比较 Jetty的架构比Tomcat的更为简单 Jetty的架构是基于Handler来实现的，主要的扩展功能都可以用Handler来实现，扩展简单。 Tomcat的架构是基于容器设计的，进行扩展是需要了解Tomcat的整体设计结构，不易扩展。 2. 性能比较 Jetty和Tomcat性能方面差异不大 Jetty可以同时处理大量连接而且可以长时间保持连接，适合于web聊天应用等等。 Jetty的架构简单，因此作为服务器，Jetty可以按需加载组件，减少不需要的组件，减少了服务器内存开销，从而提高服务器性能。 Jetty默认采用NIO结束在处理I/O请求上更占优势，在处理静态资源时，性能较高 Tomcat适合处理少数非常繁忙的链接，也就是说链接生命周期短的话，Tomcat的总体性能更高。 Tomcat默认采用BIO处理I/O请求，在处理静态资源时，性能较差。 3. 其它比较 Jetty的应用更加快速，修改简单，对新的Servlet规范的支持较好。 Tomcat目前应用比较广泛，对JavaEE和Servlet的支持更加全面，很多特性会直接集成进来。 来源： oschina

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 引言 该文主要参考了 玄霄 的分享，感觉他分享的比较细。 应用服务器目录结构 由于需要用到jetty的websocket开发，因此选用的版本是8.1.7，从上图可以看到，主要有下面几个主要目录： 1、bin目录 启动脚本的目录，也包括了start.jar，主要是用来起引导作用的，引导资源加载和服务的启动。 2、etc目录 配置文件的目录，也包括了start.ini，这份配置文件是用来指导start.jar的加载顺序和加载模块的，这个后面会有详解。 3、lib目录 库文件目录，如果需要调试jetty的话，可以下载源码加到eclipse中，客户端远程调试即可，命令： java -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8090 -DEOS_DEBUG=true -jar start.jar 4、webapps目录 应用部署目录 应用服务器启动流程 1、【流程图】 2、【start.jar】 可以看到，最后将server启动起来了，而jetty最核心的即server类，学习jetty的同学不防直接从server类的doStart()或者handle(...)入手。 3、【server.start 】

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 引言 Jetty相较于Tomcat更加轻便，虽然架构更加简单，但是看起来可并不轻松。Spring是设计初衷是用来管理应用中的实例Bean，因而是基于Bean的架构；Jetty则更倾向于流程和组件的管理，采用了基于handler的架构。handler的嵌套和链式结构，LifeCycle和doStart、doHandler模式无不印证了这点。 本文主要从基本架构、LifeCycle结构、Handler体系结构、Jetty启动过程、接受并处理请求的流程和与Tomcat的比较来简要介绍下Jetty，细节部分后面的博文会有分析。 Jetty的基本架构 前面的博文谈及应用服务期的架构已经说过了几个基本模块的概念，connection、Threadpool等~拷贝了 许令波 画的图(文中关于基本架构的描述挺详细的，参考了其目录结构哈~不过对于有些知识点有自己的看法，因此总结该文)： 该博文中谈到“ Jetty 中还有一些可有可无的组件，我们可以在它上做扩展。如 JMX，我们可以定义一些 Mbean 把它加到 Server 中，当 Server 启动的时候，这些 Bean 就会一起工作。 ”我的理解是，Jetty中的JMX是提供给server的Container，使得注册到server的Handler同时注册到JMX上

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 0、前言 架构师是一个没有被严格定义的角色。 在写这篇文章之前，我特意把这几年看过的关于架构和架构师的 书重新翻了一遍，结果发现它们的定义或多或少有一些不一样，而经过了这几年，一些之前同意的观点，现在的我也不敢苟同了。另一方面，业界对于架构师这个岗 位，其实也没有统一的角色定位。在阿里巴巴，前几年是有专职的“架构师”职位的，现在已经回归到“工程师”、“专家”、“研究员”这样的纯技术职位。而我 面试过的人中，也有各种各样的“架构师”，很多小团队里，项目经理就经常自认为架构师。大概架构师目前还不至于称为一个职业，更多的是在项目中的一个角 色，而其角色定位也是模糊的，因此，这个文章里，我主要还是从自己的理解出发，阐述一下这个角色的定位和个人发展的建议。 1、架构师的定义 架构师：任何复杂结构的设计人员。 架构师的名字来自于建筑业，Software Architect直译应该叫“软件建筑师”。从很多方面讲，软件架构师的工作跟建筑师很像，为了寻根问祖，曾经我也看了不少建筑设计的书（推荐一本《建筑的永恒之道》），最后我发现，两者一脉相承，现阶段分道扬镳，未来也许殊途同归。 一脉相承——不管是建筑师还是软件架构师，都是为了“大图”而存在，做好顶层设计，充当需求方和实施者的桥梁，是其最重要的两个职责。 分道扬镳——两者的发展

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 很久以前（4,5年前）当核心码农，只需保质保量完成既定任务。技术选型开会的时候随便yy，反正最后拍板背书的人不是我。完成特定的任务，想算法，做优化，实实在在的产出，很有成就感。 而最近这几年，开始渐渐提升自己，从架构师，技术经理，到技术负责人。现在开会不敢乱说，技术也不敢乱选。因为要给设计做最终拍板，确定最终的技术架构体系。所以会经常焦虑自己做的设计是不是有坑，是不是太low等等。 同时在公司有限的资源内，还得决定哪些先做哪些缓一缓。以前我只需要把待做的1234抛出去，具体做啥上头说了算，你说做1我就做1，不用过脑子。现在经常1234都要做，手头的资源只够做2个，优先级还得自己协调，光想这个优先级就头大。 因此在此开贴，抛砖引玉，谈谈自己对架构师职责的理解。 首先，我们应该明确，不同公司对架构师的定位不尽相同，而且也和架构师在一个项目中切入的时间点有很大关系。经历过几家公司的架构师职位，有的是以技术选型，设计阶段给技术团队提供咨询为主；有的则是系统调优，代码重构，性能优化为重；而还有些公司，CTO的设想是，产品经理提产品需求，架构师提重构和优化需求，并且作为顾问参与到所有项目的设计阶段。 在我看来，架构师对公司核心业务，组件化，耦合，解耦的理解程度如何，对新技术保持浓厚兴趣和探索