架构
-
软件架构-事件驱动架构
你好，我是看山。
本文源自并发编程网的翻译邀请，翻译的是 Jakob Jenkov 的 《软件架构》 中关于事件驱动的内容，虽然是 2014 年的文章，但是从软件架构层面上，并不过时。
以下是正文。
事件驱动架构是一种系统或组件之间通过发送事件和响应事件彼此交互的架构风格。当某个事件发生时，组件A不直接调用组件B，而只是发出一个事件。组件A不知道哪些组件监听并处理这些事件。事件驱动架构可以在进程内和进程间使用。比如，GUI框架中会大量使用事件驱动。【译者注：目前很多系统采用微服务架构，事件驱动使用的更加广泛了。】此外，正如我在并发模型教程 中所提到的，装配线并发模型（AKA reactive，非阻塞并发模型）也使用了事件驱动架构。
本文主要介绍进程之间的事件驱动架构，后文提到这个词的时候也是指进程交互方式。
-
软件架构-缓存技术
本文源自并发编程网的翻译邀请，翻译的是 Jakob Jenkov 的 《软件架构》 中关于缓存技术的内容，虽然是 2014 年的文章，但是从软件架构层面上，并不过时。
-
系统设计系列之如何设计一个短链服务
短链服务的鼻祖是 TinyURL，是最早提供短链服务的网站，目前国内也有很多短链服务：新浪（t.cn）、百度（dwz.cn）、腾讯（url.cn）等等。
不得不问一句，为什么要用短链？这个问题的另外一层意思是，短链服务有必要存在吗？
套用万金油答案：存在即合理。
-
微服务架构的陷阱：从单体到分布式单体
你好，我是看山。
前面咱们聊了架构的演进过程，提到单体架构、SOA 架构、微服务架构、无服务架构。整个过程如下图：
目前无服务架构还未成熟，只能满足一些简单场景。所以大家在设计软件架构时，首选还是微服务架构。然后我们又聊了聊如何把单体架构改造为微服务架构，推荐采用绞杀模式，一步一步的实现系统微服务化。
在这个过程中，我们会碰到微服务架构的一个大坑：分布式错觉，即将分布式当成了微服务的全部（充要条件）。
-
除了微服务，我们还有其他选择吗？
你好，我是看山。
前面我们聊了微服务的话题，现在微服务已经是业内通识。但凡系统开发、系统设计，必然采用微服务架构，或者宣称是微服务架构。
但大家有没有想过，微服务架构不是一开始就有的。如果追溯历史，微服务最早在 2005 的云计算博览会，由 Peter Rodgers 博士提出（那时候称为微 Web 服务（Micro-Web-Service））。到了 2014 年，Martin Fowler 与 James Lewis 共同提出微服务（Micron-Service）的概念，算是对概念归纳总结，天下一统。这一年也被称为微服务元年。
那就要问了，在 2014 年之前呢？大家用啥架构？再往前呢？上次互联网大潮的时候，大家又是用啥？我们今天来聊聊这段历史，可能你会对现在习以为常的架构，产生一些新的看法。在架构上，可以有更多的选择。
-
微服务的基建工作
前文说了一下《六字说出微服务的本质》，在文末提到，初创团队不建议直接使用微服务，对于初创团队，最根本的是活下去，而想要使用微服务，需要有很多基础建设。本文就来说下，微服务都需要哪些基础建设。
需要说明的是，下面这些组件，都是基于服务太多这个前提。
微服务的出现是为了研发效能的提升：相同的人数可以处理更多的需求、维护更多的产品，可以更快的交付产品。基于这点，微服务的基础组件，就从解放人力，减少人为失误出发。
下面给出一张微服务基础组件的图片：
-
六字说出微服务的本质
我所理解的微服务，就六个字：“高内聚，低耦合”。
没错，就是这个在软件开发过程中被反复提到的六个字，各类设计模式、架构设计、从入门到放弃等各种书中总会提到，从初级到高级到骨灰级程序员、架构师挂在嘴边的也是这六个字。只不过，在微服务概念之前，这六个字被用在类、模块、组件上，微服务则是将它放在服务上。
注：上面是精简版，下面是完整版，看官自便。