这个月，我和我的同事们开源了一个内部的架构治理平台：ArchGuard，我们进行了一系列的遗留系统的迁移工作：
最近的最近，在与同事对于过去架构的反思和总结中，我们讨论出了一个新的架构模式：应用微化架构。由于它是一个反向的微应用化架构模式，所以从模式上来说，我们便将名字反向了一下。由于这一种架构模式，实施和设计相当的简单。所以，在进行详细的介绍之前，先了解一下我们遇到的问题。
Mooa 是一个为 Angular 服务的微前端框架，它是一个基于 single-spa，针对 IE 10 及 IFRAME 优化的微前端解决方案。
过去的几周里，作为一个 “专业” 的咨询师，一直忙于在为客户设计一个应用拆分的服务化方案。主要是为了达成以下的设计目标：
在设计所谓的"Next-Generation CMS"，即Echoes CMS的时候，对于我这种懒得自己写Django App的人来说，通过我会去复制别人的代码，于是我继续在Github上漫游。接着找到了DjangoProject.com的源码，又看了看Mezzanine(ps: 我博客用的就是这个CMS)。于是从DjangoProject复制了Blog的代码，从Mezzanine复制了conf的代码，然后就有了Echoes的codebase。然后，继之前的文章(《微服务的小思考》我想了想， 这不就是我想要的模型么?
在一堆软件架构方面的书里混了几天，发现世界还是不一样的。
当我在告别毕业答辩之后，我开始了继续学习微服务构架的道路，而这时打开Seneca的官网，发现上一篇关于微服务框架的文章——微服务框架——Seneca，一个Node.js的微服务工具包 。显然，已经不合我的胃口，官网首页的更适合我，于是这次比上次好多了。
了解完微服务的一些知识之后，便开始寻找一些框架来玩玩这东西。
当我开始了解《微服务架构》的时候，我发现里面的中文文章是相当的少，于是开始试着翻译一些文章，比如这一篇《微服务——不是免费的午餐》。这篇文章是在某次讨论结束后听到的，和之前类似的是这种区别有点类似于之前说的微内核与宏内核的区别。
当我听到这个名词的时候还是三天以前，做为一个初入者，我觉得对于这些对于我来说还是需要去好好理解一番。有种趋势似乎是大型系统架构，越来越往这边靠拢。原因不仅仅在于系统过于臃肿，还在于如何更好的似乎小团队开始。