3.1 优点
①易于开发维护
微服务基于领域模型拆分的应用，其内部模型高度统一，功能相对内聚，开发人员只需要对固定模型进行领域业务接口封装即可。
②技术栈开放
微服务因独立部署、独立开发，因此开发团队可以根据资深团队特点进行技术选型。如团队擅长关系型数据库则MySQL，擅长图形计算则Neo4j。
③升级错误隔离
A技术专项升级因单独部署，不再影响整个分布式架构中全部功能，只影响有接口交互的部分应用，而这种应用也可以通过灰度、服务降级、服务熔断的方式兼容和处理，不会因一个错误导致整个应用瘫痪。
3.2 缺点
①运维成本高
更多的服务意味着更多的运维投入，传统应用中只有一个应用，而为服务中，需要保障几十、上百个服务的正常运行和协作。
②调用链路复杂
微服务架构中，不可避免的会出现A服务依赖B服务，B服务依赖C服务，C继续依赖D服务的场景，一旦A调用异常，排查链路可能会从A->B->C->D，才能最终发现服务报错具体信息（后续skywalking可解决）。
③分布式事务问题
同上例A->B->C->D的长链路调用过程中，如果A先修改自己数据，但下游C却异常，此时预期是A回滚自己事务，这一点在单体应用因都是本地事务可以很好做到，但是分布式场景下却提升了复杂度(后续Seata可解决)。
④学习成本高
微服务学习除了需要一定基础之外：Spring、SpringMvc、MyBatis、SpringBoot、Maven、MySQL等，还需学习SpringCloud，中间件、缓存、Docker、文件服务器等多种技术，每一门学习都有很多难点需要克服。
4.如何实现
