架构师修行之路

如果你比较关注现在的技术形式，就会知道微服务现在火的一塌糊涂，当然，事物都有两面性，微服务也不是解决技术，架构等问题的万能钥匙。如果服务化带来的利大于弊，菜菜还是推荐将系统服务化。随着服务化的进程的不断演化，各种概念以及技术随之而来。任何一种方案都是为了解决问题而存在。比如：熔…

这里还要多说一句，key的取值可以根据具体业务具体设计。比如，我想要做负载均衡，key可以为调用方的服务器IP；获取用户信息，key可以为用户ID；等等。 在服务器数量不变的情况下，以上设计没有问题。但是要知道，程序员的现实世界是悲惨的，唯一不变的就是业务一直在变。我本无奈，只…

说到系统设计的三高，每一高都是一个很庞大的话题，甚至可以用一本书甚至N本书来详细阐述。其中高可扩展性是系统架构的众多目标之一。归根结底，系统的架构要为最终的业务服务，脱离业务来谈架构其实比耍流氓更无耻。 在我们心目中最理想的软件架构要像搭积木一样简单，并且快捷，而且高效。但是现…

谈到系统架构的分层和系统领域边界的划分，每个架构师，每个技术经理，甚至每个程序员都有自己的一套想法。无论是怎么样的划分方案，总体的目标始终是一致的，打造一个高性能，高可用，高可扩展，高安全性的系统，甚至会附加上一大堆的专业名词，例如：高度一致性，可重用性，幂等性，兼容性 等等。…

随着系统的复杂性不断增加，多数系统都会引入MQ来进行解耦，其实从引入MQ的初衷来说，多数系统是为了解耦多个模块带来的复杂性，而有些“架构师”却说的：为了解决性能问题。。。当然我不排除MQ有流量削峰的作用，我只是说大部分系统引入MQ最初的初衷应该是系统解耦 。 当一个大的单体系统…

我敢说凡是做过电商的同学，都会遇到运营展开的秒杀，限时购等“高并发”的活动。市面上也有不少针对秒杀的解决方案，什么分库分表，缓存，消息队列呀，但凡能想到的技术“靓点”都基本会写上一段。我觉得应对秒杀这样的带有流量峰值的业务，还是要仔细分析业务的特性，以及根据自己系统的业务量来确…

对性能孜孜不倦的追求是互联网技术不断发展的根本驱动力，从最初的大型机到现在的微型机，在本质上也是为了性能而生。软件系统也存在类似的现象，一个系统从最初的少量访问请求到后期的大并发请求，这都需要我们对性能的提升提供一系列解决方案。像最初的淘宝，也仅仅是一个外包做出来的产品，随着业…

说到 session，我相信每个程序员都不陌生，或多或少在项目中使用过。session 这个词，其实是一个抽象的概念，它不像 Cookie 那样有着明确的定义。当大多数程序员谈论 session 的时候，可能指的是服务端存储数据的 session 对象，例如，用户登录成功之后把…

这是一个被无数程序员撸过的问题，却只有少数人了解了真相。大体上搜了一下，网上关于http协议保持状态误导大家的文章还是有的，比如：有人说利用ViewState，那是asp.net下独有的东西，请注明“asp.net下如何保持状态”！！ http协议相对我们的年龄来说，是一个比较…