热爱一切基础技术架构领域知识
## 建模 客观世界时刻处在变化中,因此稳定的模型理论上是不存在的,建模者应去洞察变化从而对模型施加预期变量,让模型的向后兼容好。 在《大象会跳舞--Thinking in UML》有对“投影(projection)”的精彩论述,当时很受启发,加上个人日常实践的感受我概括下“在尽可能多的场景中从不同角度观察客体,每个角度的一次观察就是一个投影,会发现:1)既有客体是有多个投影,2)也有多个客体
Eric Evans的《领域驱动设计》问世已经14年之久,到今天几乎所有业务团队都或多或少有涉及DDD。然而较真起来会发现,认真遵循DDD设计原则的团队仅是少数,多数团队的现状依然是: **数据库关系=模型。
## IOC ## IOC,大名鼎鼎,如雷贯耳。官方给的定义是依赖注入(Dependency Injection)或者控制反转(Inversion of Control),都相当术语化,不太容易懂。 想象下日常中的生产过程,在生产之前是客户下单,单子上会详细注明需要的产品,包括产品的各方面规格属性,然后工厂据此生产。 IOC就是一个类似的过程,我们声明需要什么,工厂据此给我们生产出来
大概两周前,团队需要对httpclient进行调优,领到任务后,大致研究了源码很快就确定了调优方向。但是对于一个重度强迫症患者,对一件事情的理解就只有两种程度,完全懂或者完全不懂,于是悲催的开始httpclient整体架构的探索之路,每天晚上回家抽点边角料的时间写,之前的理解建立在一个宏观基础上,对整体有个把握,写的过程中细节不断丰富细节,理解开始变得立体起来。背景知识 Http简介 通常,我
Java Beans == Spring管理对象是以bean为颗粒度,在最初设计时其实是特指Java beans,因此之前的注入也几乎是清一色的set注入,直到聪明的大脑们引入了Annotation后两者才有了明显差异,慢慢进化出Spring特有的bean规范。 本篇先从设计者的初衷Jav
逻辑集群 == Dubbo里两个主要参与实体是provider和consumer,两者都是相对服务而言,前者是服务的具体实现,后者是服务的消费者。 服务在客户端被异化成提供同质的服务的逻辑集群,消费者的服务请求最终都会通过集群select出一个invoker进行远程调用,整个过程对用户是非
序 == 初次接触dubbo是在2011年,当时公司项目出于成本考虑容器从Weblogic改为Tomcat,部署方式由单机改为单体多机的部署方式。对一个从没读过半本计算机书籍的人,不了解协议,不懂规范只知道SSH的菜鸟而言,完全不理解分布式的方式是如何做到互通的。晚期强迫症逼迫我一定要弄懂这其中
IOC == IOC,官方给的定义是依赖注入(Dependency Injection)或者控制反转(Inversion of Control)。光从字面理解起来还是比较费劲。但任何一种模式都是来自人的行为思考方式,只要想象下日常生产过程,在生产之前是客户下单,单子会详细注明需要的产品,包括产
背景知识 Http简介 通常,我们使用IE或者safari来访问互联网上的内容,只需要输入资源地址,浏览器便会呈现给你想要的内容。这一切的背后,都是迄今为止在计算机领域最成功的协议–http协议。 Http协议分为请求和响应,客户端建立连接,接着发送请求,服务端接受并处理请求,再发送应答,再由客户端接受并处理应答。浏览器是最最常见的一种客户端,它将用户的交互行为作为
花了两天的时间研究了下Diamond,因为写得比较急,而且并没有使用过,只是单纯的做逆向建模,所以难免会有细节缺失,后面会时不时过来看看,然后做些补充。 背景知识 早期的应用都是单体的,配置修改后,只要通过预留的管理界面刷新reload即可。后来,应用开始拆分,从单一系统拆分成多个子系统,每个子系统还会对应多个运行实例,就开始面临一些问题: 1. 配置分散在多个业务
之前写过一篇dubbo cluster–架构。因为dubbo逻辑集群的功能主要是在client端,主要侧重在client的分析。后来因为工作忙和懒癌,也就没再继续server的叙述了。最近正好在看大众点评的cat源码,其中也有rpc的模块,就借此专门来分析下rpc server的实现。 网络模型 Cat server基于netty,是典型的reactor模型。 上图
概念 Context也就是我们常说的spring容器,打个比方,context就像是一家公司,beans则是公司的工厂,除了工厂,公司还有翻译,仓库以及办公场所等等。 下面就看看context的主要构成部件。 Context构成部件 上图是ApplicationContext的实体静态结构,它继承了六个实体。虽然是继承,但其实context和他们的关系更像是聚
在打造集中化日志那篇中,稍微提了下Elastic search。 Elk打造集中化日志 Elastic search是Elk的核心,写的时候重点也放在它上面,不过还是觉得深度挖掘得不是太够,所以决定再另写一篇重点介绍下Elastic search。 正如那一篇博客提到的,如果你不是喜欢夜店咖,就像千千万万的程序员一样喜欢本本分分的女人,最好再稍微带几分姿色,那选ES准没错
Elk是Elastic search, Logstash和Kibana三者的简称。 Elastic search顾名思义是致力于搜索,它是一个弹性搜索的技术平台,与其相似的有Solr,二者的对比可参考下面这篇文章: Elastic search与Solr选型 总结一下就是,如果你不喜欢夜店咖还是喜欢忠实可靠的老婆,那选Elastic search准没错,何况他还有那么一点
session通用策略 Session在浏览器通常是通过cookie保存的,cookie里保存了jessionid,代表用户的session id。一个访问路径只有一个session cookie(事实上在客户端就只有一个cookie,jsessionid是作为cookie值的一部分,这里把cookie抽象成类似服务器端的实现),也就是一个访问路径在一个浏览器上只有一个se
spring session的生命周期 Session获取 spring-session实现了HttpServletRequest的子类–SessionRepositoryRequestWrapper,由它覆盖getSession方法,将由web容器处理的逻辑接管过来。 public HttpSession getSession(boolean create
ServletRequestWrapper Servlet规范从2.3起引入了ServletRequestWrapper包装类,它把调用交给被包装的ServletRequest来执行。这样就可以对ServletRequest进行扩展。例如Tomcat就是将自己的Request类作为包装类的实体。 public class ServletRequestWrapper i
启用redis session spring通过EnableRedisHttpSession注解来启用redid session @Import(RedisHttpSessionConfiguration.class) @Configuration public @interface EnableRedisHttpSession { int maxInacti
ServletContainerInitializer ServletContainerInitializer 也是 Servlet 3.0 新增的一个接口,主要用于在容器启动阶段通过编程风格注册Filter, Servlet以及Listener,以取代通过web.xml配置注册。这样就利于开发内聚的web应用框架。 例如Spring,我们使用它的web功能时,需要在we
http的缓存协商 浏览器对静态文件的缓存主要是通过cache-control来控制的,cache-control可以设置no-cache,max-age以及must-revalidate等来设置缓存策略。 如果max-age> 0则会在max-age的时间内不访问服务器,用本地缓存的静态文件代替。 如果max-age<=0则会每次都询问服务器,资源文件是否有修改,
我们对cookie的了解往往停留于浏览器的层面,但cookie其实是http协议的一部分,不管服务器端还是浏览器端都需要遵循它。cookie是由服务器第一次应答请求时生成,然后通知浏览器进行缓存,下一次提交时会把当前所有的cookie都提给浏览器,需要注意cookie并不只一个。 在浏览器端以 key=value;key=value的字符串形式存在,分号隔开的两边各位一个cook