思考：你的互联网+项目为何敏捷不起来？四、微服务与敏捷实施团队的拆分

微服务是在SOA、模块化、分布式等软件架构之后出现的，是一个大的单体应用在发展到一个瓶颈（性能瓶颈、功能复杂）后，为了解决业务复杂性以及适应敏捷，经过纵向分解、分布式计算、数据分片分而治之后而出现的。技术上也出现了与之正对应的云部署平台，如Kubernetes,AWS,Pivotal Cloudfoundry等。

但微服务本身，并不是云，微服务是在弹性云计算平台出来能够大幅度简化与提升运维效率与成本的条件下才广泛应用的。

微服务具有SOA所有特性要求，只不过微服务的部署粒度更细（模块级），更体现从前（表现层）到后（数据层）的整个通道的独立性与隔离性。SOA的互操作性、位置透明等特性依然有效。

微服务和单体应用的其中一个重大差别是前者是一棵服务依赖树，而后者是一个图。

在单体模型中，一个典型的服务栈可能包含一个“Web组件组合（web array）”，它调用一个缓存层、数据库层，可能还有一些独立服务，比如身份验证，等等。在微服务模型中，你会有一个连通图或者服务网络，每个服务都依赖于几个其他的服务。有一点很重要，就是要确保这个图是一个有向无环图（DAG），否则你会陷入依赖地狱，可能还会遇到分布式堆栈溢出错误。

每个概念都有自己鲜明的个性和目的，否则就是通过包装不同的概念来耍流氓。

那么，微服务的有哪些鲜明特性？

1、细粒度（模块级）

2、业务自包含

2、技术架构独立演进

3、互访基于开放标准

4、独立部署，物理上的隔离性。

微服务应立足于业务复杂性和性能规模要求，而不为微服务而微服务，企业实施微服务，应考虑自身的几个条件：

1、人力资源是否充足 ，因为微服务的拆分往往意味着实施团队也要随着微服务拆分，可能需要更多的资源

2、运维水平是否已经实现自动化，是否到了容器即服务（CaaS）阶段

3、是否有集中监控平台，一个没有集中监控日志的微服务是灾难性的

4、更高的管理要求，微服务实施团队之间的依赖、沟通，需要管理

依据微服务规划与设计而进行的团队拆分是合理，这样的团队，它们的依赖关系，体现了了业务流程环节中，后续环节对前序环节的依赖，而不会导致无序依赖，它的项目管理也应该是高效的、有序的。