微服务选型

众所周知，微服务是一个以业务功能为主的设计概念，每一个服务都有自己的业务功能。

微服务，从其概念来看，就是一个个单一(这块依赖于自己的实现)业务功能实现的服务，特点是功能单一简单，业务耦合度低，服务之间调用支持多种方式(http、tcp)，某个微服务的故障不至于影响整个服务集群。

微服务架构逻辑图(图片来自于网络)

与微服务相对的，是集中式服务或者单体服务(本文中将均以集中式服务来表述)。所谓的集中式服务，是将某业务的所有功能，均放在一个server中来实现，这样的好处是：

1、开发简单直接，集中式管理

2、基本不会重复开发

3、功能都在本地，没有分布式的管理开销和调用开销

当然，他的缺点也很明显：

1、开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断

2、代码维护难：代码功能耦合在一起，新人不知道何从下手

3、部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长

4、稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉

5、扩展性不够：无法满足高并发情况下的业务需求

微服务架构的优点：

1、将集中式服务的功能，拆分为多个微服务，这样将一个复杂的业务功能，拆分为多个简单的业务功能

2、微服务单独部署，不至于影响其他微服务

3、每个服务单独部署，这样可以将CPU密集型与非CPU密集型的服务混合部署，这样一定程度上节省了部署成本

微服务架构的缺点：

1、分布式部署，各个业务以http或者RPC方式进行调用，一定程度上增加了调用的复杂性(相比于集中式服务的进程内函数堆栈调用)

2、服务之间协议的选型，比如某个服务因为业务需要，增加了某些字段，那么对应的跟该服务相关的业务服务都需要进行协议更新

3、需要较好的策略部署和高度自动化水平

4、对于人员较少的部门，如果选用微服务方式，可能会增加维护成本，所以需要更好的了解业务知识，以便能够正确的进行微服务功能设计

笔者从事于互联网行业，负责过推荐引擎，广告引擎等，基本都是以微服务方式来实现，比如阿里妈妈，快手等广告后台架构，均以微服务方式来实现。

后续，微服务将作为某一个系列，介绍如何实现一个高性能的引擎，跟随笔者一起探索。