方丈的寺院

随着需求的不断迭代，服务承载的内容越来越多，依赖越来越多，导致服务启动慢，从最开始的2min以内增长到5min，导致服务发布很慢，严重影响开发效率，以及线上问题的修复速度。所以需要进行启动加速。

几年前我总结过DDD战术设计的一些可落地的经验，现在回过头来发现，当初对这些概念的理解还是没有到位。战术设计的各个模块是如协作的。哪些是问题空间问题，哪些是解方案空间问题 这篇文章重新阐述下。

在微服务架构下，我们习惯使用多机器、分布式存储、缓存去支持一个高并发的请求模型，而忽略了单机高并发模型是如何工作的。这篇文章通过解构客户端与服务端的建立连接和数据传输过程，阐述下如何进行单机高并发设计

几年前我在可落地的DDD的(2)-为什么说MVC工程架构已经过时总结了基于DDD的微服务工程结构是怎样的。那篇文章重点阐述了与MVC架构的区别。导致一些细节没有讲清楚，本文结合最近两年的实践，做些补充

新晋管理者总是手忙脚乱的。领导管你要技术规划;一堆业务需求提过来了，如何判断做不做，任务应该分配给谁;原来和组里同事都是平级，现在我是领导了，好像有几个人不太服，我该怎么处理呢。千头万绪。

在web开发过程中，经常会遇到接口RT高的情况，除了通过监控事后优化的方式，我们还需要掌握一些常用的手段，避免写出慢的接口。从前端发起调用到后端一般经过网关层、应用层、存储层。每一层都可以优化，

随着业务的发展，微服务越来越多，缓存相关的场景也比较多，通常的做法是基于缓存数据库（如redis),client来进行缓存操作。这样的问题有两个 如果更换缓存数据库改造成本比较高 对于批量查缓存

作为团队架构师/技术负责人你该如何进行微服务的划分呢?在以前的文章中讨论过这个话题，可落地的DDD(4)-如何利用DDD进行微服务的划分(2)，最近结合在不同的开发团队实践，又有了新的思考

最近和朋友，同事交流了一些关于技术人如何成长的话题。为什么聊到这个话题，因为程序员这个职业发展真的很快，2、3年的时间，相同起点的人可能就会被拉开很大差距，所以技术人一定要持续学习，保证一定的成长速度，才能跟上技术的更新和不断拍来的后浪。 职业成长体系总是会提到2个维度，喜欢的…