微服务——服务的拆分

我在思考一个问题：我们为什么要搞微服务，整体式服务就不能满足吗？为什么一定要用微服务呢？

服务的粒度拆的约来越细呢？当我们的业务复杂之后，设计一个系统难度会加大，还要适应快速迭代，就更难了。

将业务的功能拆分之后，会让每个模块的设计变得简单。对于需求的变更，采用增加、修改模块的方式来实现也比较方便。

但是，微服务同样带来了新的问题。

1、通信。模块间的数据交流，增加了通信成本，我们采用rpc的方式来处理模块间的通信。在选用协议的时候，

要考虑通信效率，扩展性，目前比较常用的是json和Protocol Buffers

2、命名。模块变多，迭代更新快，这就需要一个可扩展、方便理解的方案来命名、分配标识符、地址。

3、一致性与副本。为了避免出现访问瓶颈，对数据对象进行复制是有必要的。这会带来副本/缓存的一致性问题。

这又涉及到如何取舍访问的粒度。

4、容错。任何下游连接、节点、进程错误的情况下保持操作正确、高效。因此需要具备自稳定性、检查故障、故障恢复还原的能力。

5、API和透明性。模块和接口太多，除了用接口文档说明以外，最好定义一套通用的风格，比如REST api，方便调用方。

6、安全。涉及到用户隐私的数据，以密文的形式进行传输。