理解微服务
关于微服务架构的文章和资料已经不甚枚举，有兴趣的可以先参考Martin Fowler的大作。这里谈谈个人对微服务架构的认识和理解。
软件设计的本质问题
软件设计最终的追求是高内聚、低耦合，各种各样的编程语言、框架、原则、模式都是为了帮助我们达成这个目标。满足这种特征的软件具有更好的可扩展性、可伸缩性、可维护性。
微服务架构也不例外。通过将服务划分为多个、独立的微服务，消除单体程序中存在的紧耦合；各个相互独立的微服务可以独立开发、维护、部署和升级。关于微服务的优势和劣势在此不再赘述，已经有很多的资料对此进行解释。
Erlang
Erlang跟微服务实际上没有什么直接的关系。但是这门语言的设计哲学使得我们能发现它跟微服务之间的一些内在关联。
Erlang具有以下特征：
- 轻量级进程。单台PC机上可以创建数以万计的进程。
- 消息驱动。进程之间通过消息进行交互。
- 容错。进程之间的链接、监督使得系统更可靠。
- 通过进程组管理进程。
这些特征使得Erlang开发出来的系统天然地就类似于一个小型的微服务系统，两者看上去颇有几分神似。
框架、工具
微服务架构是当前互联网应用的流行架构模式，最近十分火热。从各种论坛、会议、演讲中可以看到各种框架和工具的出现，甚至有人说，不用XXX的系统就不是微服务架构。
用不用框架、工具，跟是不是微服务架构没有必然的联系。架构不等于框架和工具的堆积。从理论上讲，不用任何框架和工具，同样可以开发出高内聚、松耦合的系统，只不过框架和工具的存在让我们可以站在巨人的肩膀上前进。
实施微服务
一种架构的成功落实和实施，离不开文化、团队、流程、技术等方面的支撑。
- 持续改进的自组织团队
就像康威定律所说，一种架构的实施对应着一种组织的形式。为了实施微服务架构，也需要有相应的组织结构。
小而精的团队往往更有战斗力，没有强力干预的自组织团队更容易产生高质量的软件。在类似蚁群、神经网络、免疫系统等复杂自适应系统中，没有中央控制者进行管理和指挥，却运行的非常良好，尽管其中的奥秘至今还不为人知。 - 敏捷实践
如果说团队的自组织从文化上保证了一种架构的成功实施，敏捷实践则从流程层面为架构的成功实施提供支持。 - 技术能力
软件领域的技术能力是团队和组织实施架构的基本功。它让我们具有良好的洞察力，识别出快速变化中的变与不变，也是架构得以成功实施的基础。
借鉴意义
看待事物往往可以从三个不同的层次出发，分别对应着价值观、原则和实践。比如，我们经常谈到的敏捷，这三个层次分别对应着一棵树的树根、树干和枝叶。
对于微服务架构，我个人认为属于原则层面。软件设计的本质复杂性问题并没有革命性的突破，技术的发展更多地体现在原则和实践层面。
微服务架构也不是下一个银弹，也不可能适用于每一个领域，但是其背后的思想却值得我们借鉴。
