概述

目前微服务已经火了一段时间了，各大互联网公司都普遍采用了微服务技术作为大型系统架构的解决方案，今天主要对于微服务做个简单总结。

什么是微服务

微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。

总结一下上面的话，可以看出，微服务有以下特性：

1.每一个微服务可独立运行在自己的进程里

2.一系列独立运行的微服务共同构建起了整个系统

3.每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，如“订单管理”、“用户管理”等。

4.微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。

微服务与单体服务的对比

下图左侧是一个单体服务，右侧是一个微服务群：

左侧的单体架构，所有的模块放在一起，共享UI以及数据库等资源。

右侧的微服务，每个模块单独运行，并且每个模块有自己的数据库。例如订单模块是IO密集的，它的数据可能使用Redis进行存储；而电影模块的数据适合使用关系型数据库，那么它的数据可能使用Mysql进行存储。它们相互之间通过一系列轻量级的通信机制进行通信。

所以这里可以得出，微服务的特点为：

●易于开发和维护
●启动较快
●局部修改容易部署
●技术栈不受限
●按需伸缩
●DevOps
●运维要求更高
●分布式的复杂性
●接口调整成本高
●重复劳动

微服务的设计原则

了解了微服务的细节后，接下来看看微服务的设计原则

微服务的设计原则如下：

●单一职责原则

指的是每一个微服务模块，只关心自己的业务规则。例如订单模块只关心订单的相关业务，不牵扯其他业务的逻辑。

●服务自治原则

每一个微服务模块的开发，需要有自己的开发、测试、运维、部署这一条独立的栈，并且有自己的数据库等一切，完全把其当成一个单独的项目来做，不牵扯到其它无关业务。

●轻量级通信原则

微服务的通信协议需要跨平台、跨语言的通信协议，因为微服务是不绑定技术栈的，不论使用Java、PHP还是.net去开发Web系统，它们之间的通信一定是去语言特色的。

●接口明确原则

前面提到了微服务的“接口调整成本高”，那么怎么去避免它呢？我们一开始就应该规划好微服务的模块是一种什么样的模型，尽量去避免A接口的改动会导致B接口的改动这种情况。

后面小编会分享更多devops和DBA方面内容，感兴趣的朋友走一波关注哩~