Linux的I/O模型
I/O顾名思义就是输入输出，I/O设备可以指网卡，键盘，打印机等，在这里为了方便讨论，I/O专门指网络设备.
之前也看过不少专门讲I/O的帖子和文章，其中有不少帖子有误导的嫌疑，比如打一些不恰当的比喻，所以我有了一种想重新梳理一下I/O模型的冲动。
- 背景
- 一些预备知识
- 同步阻塞
- 同步非阻塞
- I/O多路复用
- 异步非阻塞I/O
- 其他
- 总结
Java之离弦之箭 - 高并发
一个系统如果足够稳定，而且客户对它也很满意，我们一般没有去优化它的必要，但如果随着用户量增加，系统变的缓慢，我们就有优化它的必要性了. 借用我前面博文《一种可以衡量事物的指标-快和好》，一个系统追求的目标之一是快，但快的前提的是
好，也就是稳，否则步伐太大了就容易扯着蛋了. 优化系统是大的话题，这里只讨论其中的一个小领域-高并发.
任何一个计算机的问题，都能从现实中找到雏形和模型，高并发也不例外。高并发的内容还是比较多的，所以不同类型的高并发问题需要不同的角度，就好像作战的时候，战斗机需要在高空1万米，也需要突然下降到高空1千米，也有可能是潜艇下沉到水下几千米配合作战. 这种思维模型我给它取了个名字叫“海陆空”模型.
- 什么是并发？
- 为什么需要并发？
- 如何使用并发？
- 并发的身影
- 并发的未来？
什么是并发？
从现实的角度，并发像什么？
在现实世界里，我们做事是有顺序的，比如做完了事情1，再做事情2, 也有可能是没有顺序的, 事情1和事情2是可以同时进行的. 所以我们在这里看到两个特征
- 事情是可以拆解的
- 从人的观察者角度，在一个时间窗口(t0-t1)内，事情是同时进行的.
在这里，我没有没有提到任何程序领域的术语，换句话说，上面的这两个特征在管理学是常见的，这两个特征可以认为是并发的雏形.
本文仅仅讨论狭义上的并发：基于线程的多任务。
Java之黑暗森林 - JVM
一直以来，JVM是Java开发者进阶过程必然要遇到的一块知识点。JVM离绝大多数开发者的实际工作还是比较远的，让人感觉是一个华而不实的东西。或者说有某一类群体，学习JVM就是为了面试，而且是以机械背诵的方式来学习JVM的，这都已经背离了学习一个知识的初衷.
- 什么是JVM
- JVM主要解决了哪些问题？
- JVM点滴
尘埃落定-k8s
K8s已经成为了容器编排的事实标准。k8s一路走来也有些曲折，但最终笑傲群雄。它这一路走来发生了哪些恩怨情仇呢？
- 背景
- 什么是k8s?
- 为什么是它？
- k8s底层是如何实现的？
- k8s生态及相关
Docker初回忆
从第一次接触Docker到现在大概也有两年多了, 基本上停留在用的层面.
现在是时候回顾一下这项革命式的技术了.
- 什么是Docker?
- 为什么是Docker?
- Docker是如何实现的？
- Docker的实践
- Docker的未来
微服务架构二三事
就现阶段而言，DDD已经成为微服务设计的事实标准，也不排除未来可能是有更好的微服务设计标准。
这篇文章聚焦于传统的架构应该如何过渡到微服务架构。
- 传统三层架构
- 传统的DDD分层架构
- 依赖倒置的DDD分层架构
- DDD 五层架构
- DDD 六层架构
- 六边形架构
- 整洁架构-洋葱模型
系统的约束和动力
一个系统能发展是有动力，如果要让系统发展的好则需要约束。就好像汽车的前进是靠发动机，汽车的减速靠的是刹车，汽车行进的方向靠的是方向盘。发动机是动力，刹车和方向盘是约束.
那么动力和约束与生活有什么关系呢？ 让我们从直觉和感性的角度来一场探索之旅吧
- 系统的动力
- 系统的约束
- 约束和动力之间的关系
闻香识微服务
微服务已经成为了后端开发的主流，也成为了后端初次见面打招呼的内容.
微服务三个字从这字面上可以理解，但它的内涵确实是各人有各人的理解，因为微服务本身并没有被严格的定义.噢，不， 它有被定义，只是在不同的时间段被不同的权威的人定义了，据可查的资料，大概有4位专家前后给出了不同的定义，所以大家都不知道真正的定义是什么了， 也不知道未来微服务的定义会变成什么样. 因为它没有像数学公式被严格的定义。
这篇文章不试图搞清楚微服务的确切含义是什么，因为这这样做是徒劳无功的。
本文试图探索
- 微服务大概是什么？
- 为什么是微服务？
- 要实现一个微服务，它应该具备哪些行为和特征？
- 微服务的未来
- 微服务带来的副作用
