chuixue24的博客

价值流往往就是顶端的流程，业务能力的分解往往是2~4级，对于详细的业务流程的分解往往就到了5~7级，只是原来在业务架构里面，我们没有太强调流程架构，实际上从架构的Y模型里面可以看到，在业务架构里面是有两个视角，好了，应用功能实现的时候，它一定会涉及到数据域的逻辑模型的支撑，所以说这个地方也会有关键的一条线，好了应用功能最终要落地到it的基础设施，或者是基础设施的一个架构，这个就会涉及到了技术架构。对于5~7级的流程，我们详细的去做流程建模和梳理的时候，里面就是有三个关键的元素，

OLAP（On-line Analytical Processing，联机分析处理）是一种用于分析和查询大规模数据集的计算机处理技术。OLAP技术主要用于多维数据分析和数据挖掘，通过提供多维数据模型和多维查询功能，帮助用户从不同角度和层次上对数据进行分析和查询，侧重分析决策。BI模块数据可视化组件。为用户提供拖拽式的数据分析操作页面，以及各种报表、图表的展示。本质上它就类似一个客户端，通过配置连接到各种OLAP引擎上（可以直白的理解为各种DB）来完成数据的分析和查询。

主版本号：当你做了不兼容的 API 修改，次版本号：当你做了向下兼容的功能性新增，修订号：当你做了向下兼容的问题修正。先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。在软件管理的领域里存在着被称作“依赖地狱”的死亡之谷，系统规模越大，加入的包越多，你就越有可能在未来的某一天发现自己已深陷绝望之中。在依赖高的系统中发布新版本包可能很快会成为噩梦。如果依赖关系过高，可能面临版本控制被锁死的风险（必须对每一个依赖包改版才能完成某次升级）。

在微服务架构体系里面，我们一般会使用到微服务网关或叫API网关。大家都比较清楚，在微服务架构体系下本身是去中心化的架构，通过服务注册中心来实现服务注册发现和消费调用，那么为何又需要使用API网关？在传统的ESB总线进行服务集成的时候我们就经常谈到一个概念就是位置透明，即需要屏蔽底层业务模块提供API接口服务地址信息，并实现多个微服务API接口的统一出口。即类似设计模式里面经常谈到的门面模式。如何给API网关一个定义？

微服务转型-架构规划业务架构和数据架构应用架构的规划和建设微服务转型-服务拆分微服务转型-和敏捷方法论集成微服务转型-实施前技术储备微服务转型-实施步骤

数字化转型方法论企业架构和SOA架构规划企业私有云PaaS平台和微服务架构规划云原生转型和技术平台规划数字化转型-从消费互联到产业互联

我们采用禅道项目管理工具统一敏捷研发管理，需求拆分到用户故事点实现端到端管理，形成产品-微服务两级的产品架构和版本管理体系，实现和持续集成和版本发布过程集成。我们首先进行粗颗粒度的模块拆分和集成分析，在分析完成后储备可以明确的识别出类似报账，资金，发票，电子凭证，影像，预算，ERP。平台的集成，即最终的编译构建完成的内容形成镜像并放到镜像仓库，后续部署，环境迁移，资源扩展基于镜像仓库进行快速的拷贝和复制。架构很难进行更好的多团队分工，同时在异地协同过程中对于开发，测试，前方实施经常出现大量的无效沟通情况。

数据架构的作用首先是找到所有的业务对象 和数据对象。在数据对象分析里面有一个重点就是主数据识别和分析。

1. 引言现阶段，在同城带宽时延问题没有经过大规模的生产实践、验证的情况下，我们只导入“白名单或1%“的小比例请求流量，进入双活环境，确保环境有效的（活的），同时能支持“容灾切换“。那么，请求流量如何导入双活环境？有哪些分流方法？存在什么样的问题和挑战，需要注意些什么？本文将从这些角度进行剖析。2. 流量分流方法流量分流的主要方法有：1、HTTP-DNS2、公网GSLB（公网DNS+公网F5出口）...

1、Redis集群方案比较 哨兵模式 在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。内存一般设为8G左右，不超过.

Redis持久化 RDB快照（snapshot） 在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。 你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次 数据集。 比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次 数据集： # save 60 1000 //关闭RDB只需要将所有的save保存策略注释掉即可 还可以.

官方架构图：组件分析：

应对业务量的不断增加场景通常有两个大方向，一种是纵向扩展，也就是增加单台服务器的CPU计算能力、内存容量和磁盘承载能力等；另外一种是横向扩展，也就是通过增加服务器的数量来增加处理能力。前者存在业务中断和扩展上限等诸多的问题，特别是互联网业务的迅猛发展，单台服务器几乎无法满足业务负载要求，因此目前比较流行的方式横向扩展的方式。1.数据库集群数据库的横向扩展是通过数据库集群实现的。数据库集群也有两种主要形式，一种是主备(主从)架构，也就是只有一台服务器上的数据库可以访问，另一个(多个)服务器上数据库不.

类与类加载器、Class< T>对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每 一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一些：比较两个类是否“相 等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个 Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。这里所指的“相等”，包括代表类的Class对象的equals()方法、isAssig

目录JDBC案例分析JDBC中的SPI校验实例的归属Tomcat与spring的类加载器案例Tomcat中的类加载器Spring加载问题解答源码分析总结前置知识：java类加载器不完整分析#前言此前我对线程上下文类加载器（ThreadContextClassLoader，下文使用TCCL表示）的理解仅仅局限于下面这段话：Java 提供了很多服务提供者接口（Service Provider Interface，SPI），允许第三方为这些接口提供实现。常见的.

零：简单工厂模式（1）设计思想：（a）单个方法（b）多个方法：(2) 应用场景：总体来说，工厂模式适合：凡是出现了大量的产品需要创建，并且具有共同的接口时，可以通过工厂方法模式进行创建。在以上的三种模式中，第一种如果传入的字符串有误，不能正确创建对象，第三种相对于第二种，不需要实例化工厂类，所以，大多数情况下，我们会选用第三种——静态工厂方法模式。创建型模式（5种）一 ：工厂方法模式（Factory Method）（1）设计思想 ：（2）应用场景：其实这个模式的好处就是，如果你现在想

Restful API 近年来应用越来越广泛，各大互联网公司纷纷推出了自己的 Restful API 服务。本文将从实际应用出发，从 REST 到 Restful 再到 Restful API ，逐一进行介绍和分析。REST 风格REST 风格最早由 Roy Thomas Fielding 博士提出， REST 是一种系统架构设计风格，主要面向基于网络的软件架构设计。这一架构风格，包含了以下一些基本要求：客户-服务器在 REST 风格中，最基本的要求就是对于一个程序来说，应当分离用户接口

在从一个初级程序员到架构师的修炼过程中，画架构图是一门必修功课。我最开始画图的时候，一直搞不清楚该画什么样的图来表达，网上也找不到系统的资料。这里整理了下这些年的知识储备，给一些刚迈入架构师或想要进入架构师行业的同学，一点点参考。架构图是一个统称，按视角维度，可分为：业务架构、技术架构、系统架构、应用架构，下面贴一些自己画的图给大家参考，个人能力有限，如果大牛有不同的看法，还请指正，大家互相交流学习。一、应用架构（平台架构）站在整个平台视角，描述整个平台架构。二、技术架构.

画架构图分四步走：第一，搞清楚要画的架构图的类型；第二，确认架构图中的关键要素（比如产品、技术、服务）；第三，梳理关键要素之间的关联：包含、支撑、同级并列等；第四，输出关联关系清晰的架构图。应用架构图接下来，我们作进一步解读：一、架构图的定义及作用什么是架构图？维基百科、百度百科其实都没有关于它的直接定义。不过我们可以进行拆分理解：架构图=架构+图这样问题就转化成，什么是架构，以及什么是图？关于架构，百度百科上是这样定义的：架构，又名软件架构，是有关软件整体

学会了面向对象的语法，却依然写不出面向对象的程序，因此我们需要了解如何从需求分析到面向对象设计这样一个过程。一，什么是领域模型领域建模。 从领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向对象设计的一座桥梁。顾名思义,就是显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。（...

作者：光太狼链接：https://www.zhihu.com/question/42061683/answer/251131634来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。对于SOA，感觉这个概念性的东西没那么容易理解，看了各位大神的解释感觉很多都说的很抽象，所以想尝试用自己的语言解释下，仅做参考。SOA粗暴理解：把系统按照实际业务，拆分...

当我们想用一张或几张图来描述我们的系统时，是不是经常遇到以下情况： 对着画布无从下手、删了又来？ 用一张图描述我的系统，并且让产品、运营、开发都能看明白？ 画了一半的图还不清楚受众是谁？ 画出来的图到底是产品图功能图还是技术图又或是大杂烩？ 图上的框框有点少是不是要找点儿框框加进来？ 布局怎么画都不满意…… 如果有同样的困惑，...