微服务 边界

微服务是用来快速响应用户需求的技术解决方案，是分布式的典型应用，那么如何划分微服务粒度，这是个架构决策

对比单体结构，微服务架构划分出来的单个微服务块与单体中的模块功能类似，其实都是逻辑上内聚的功能集合，不同点在于微服务通过网络通信，而单体则通过jvm中api依赖

当然由于其通过网络通信则需要考虑网络因素带来的各种后果，比如网络抖动，网络无法连通，以及网络通信的性能代价，由此衍生出的服务的容错幂等以及一致性等分布式设计要素

以及部署的容错，扩展等

基于微服务的功能特性，做如下操作：

功能划分

那么功能怎么划分呢，作为打通业务开发运维的架构师，他的职责就在于在完成客户需求基础上，尽力降低成本。那么这个成本都有那些呢，主要为业务梳理之后的所有成本，主要是开发与运维。

所以划分时要考虑业务功能因素，开发因素，运维因素。

首先依据业务梳理来的场景特性基础流，扩展流，异常流等划分模块，比如网络购物过程中，我们一边浏览商品，之后下订单及付款这个流程，此时则可划分产品模块，订单模块及交易模块。

模块验证

此时考虑已划分的功能模块是否存在过多的变更因素，致使你的模块频繁变动；是否过于繁杂，致使开发人员难于理解；为了完成某一功能是否需次序调用多个；模块服务致使性能不佳；模块是否

涉及了过多的数据库，致使模块间一致性问题突出；是否模块之间通信杂乱，致使运维困难；

此时架构师需与SA，开发经理，运维经理等不断评审，查漏补缺，确保各方达成一致意见，此时方可投入实际开发。