微服务架构综述

微服务架构在近几年一直很热门，尤其是随着敏捷开发、持续集成交付、DevOps、云技术、虚拟技术docker化等的深入人心，经常能在技术论坛，博客上看到相应的文章推送。正好现在我们之间使用的也是微服务架构，将一个原本巨大的单体应用进行拆分（比如有基础服务，用户中心，有提供给PC,H5的服务等），用RPC框架HSF进行微服务之间的通讯以及服务治理。于是我对微服务的概念有了一定的体会，想结合自己看过的一些文章对微服务的概述进行一个总结。

一.传统的单体应用

传统的开发单体式应用，随着系统变得越来越大，最终会达到一个临界点，作为一个单体（monolith）它变得难以管理。每一行代码的添加，都会让系统变得更加难以理解、变更和重用。架构图如下：

应用核心是业务逻辑，由定义服务、域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件，以及提供API或者UI访问支持的web模块等。

一个简单的应用会随着时间推移逐渐变大，单体式应用的不足有：
1. 敏捷开发和部署举步维艰，其中最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正bug和正确的添加新功能变的非常困难，并且很耗时。
2. 单体式应用也会降低开发速度。应用越大，启动时间会越长。
3. 复杂而巨大的单体式应用也不利于持续性开发。今天，SaaS应用常态就是每天会改变很多次，而这对于单体式应用模式非常困难。
4. 单体式应用在不同模块发生资源冲突时，扩展将会非常困难。
5. 单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄露，将会有可能弄垮整个进程。除此之外，因为所有应用实例都是唯一的，这个bug将会影响到整个应用的可靠性。
6. 单体式应用使得采用新架构和语言非常困难。

总结一下：一