业务能力
通讯机制
松耦合
服务的独立部署每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性低。
服务的快速启动拆分之后服务启动的速度必然要比拆分之前快很多，因为依赖的库少了，代码量也少了。
更加适合敏捷开发敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布。
职责专一，由专门的团队负责专门的服务业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。
服务可以动态按需扩容当某个服务的访问量较大时，我们只需要将这个服务扩容即可。
代码的复用每个服务都提供 REST API，所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。
分布式部署，调用的复杂性高单体应用的时候，所有模块之前的调用都是在本地进行的，在微服务中，每个模块都是独立部署的，通过 HTTP 来进行通信，这当中会产生很多问题，比如网络问题、容错问题、调用关系等。
独立的数据库，分布式事务的挑战每个微服务都有自己的数据库，这就是所谓的去中心化的数据管理。这种模式的优点在于不同的服务，可以选择适合自身业务的数据，比如订单服务可以用 MySQL、评论服务可以用 Mongodb、商品搜索服务可以用 Elasticsearch。
测试的难度提升服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了。这里要强调一点，就是 API 文档的管理尤为重要。
每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
微服务能使用不同的语言开发。
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
微服务允许你利用融合最新技术。
微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
微服务架构可能带来过多的操作。
分布式系统可能复杂难以管理。
当服务数量增加，管理复杂性增加。