微服务架构优势和劣势

一、 面向服务架构

面向服务(SOA)具有松散耦合，标准化接口，可重用重服务，的特点。

在电商领域中，抽像出会员服务、商品服务、订单服务等服务。

这样按服务拆分的优势：

每一组服务的接口明晰，开发人员面向统一的服务接口开发（遵循约定好的契约），不需要关心服务实现的细节，使得每一个服务可以由专门的团队精研、专注这个服务的业务，方便组织大规模的团队开发。

面向服务开发的劣势：

要求团有面向服务开发的经验，熟悉服务于服务间的契约、规范的指定。

同时会带来调试的复杂度，原因是由简单的类调用变化为服务调用，A服务又可能依赖B、C、D服务的调用，形成复杂链路，要求团队有丰富的服务mock（模拟）经验。

二、 扩展和扩容

微服务架构是去中心化的、服务自动注册和发现的，这使得应用扩容变得容易，服务的新增和复本的新增都是自动发现、自动负载的，这使得扩容变得很容易。而且可以针对热点业务进行单独扩容，如订单业务并发较高，可只针对订单服务进行扩容，在单体应用的集群场景中，如果要扩容，就只能将所有业务一起增加副本。

但同时微服务的部署相对复杂，因为按服务拆分后，服务的个数都较多，以电商领域Legendshop的拆分方式来举例,，一些基础的服务（图片服务、短信服务、邮件服务）加上电商业务本身服务（商品、订单、会员、统计等），还要有服务注册和发现（注册服务、网关服务），就要有10至20个服务。这就要求团队有相应的devops（自动化的可持续集成）经验和能力，因为手动去部署、运维这么多服务是不可想像的。

三、 服务降级和熔断保护

在基于spring cloud 体系的微服务架构中，有较完善的服务监控、服务降级和熔断机制。

熔断：因为如果某个服务发生了人力不可抗的崩溃（如宕机、停电或断网），会发生雪崩效应，这时应尽可能的保护其它服务可用.

降级：在大规模访问发生时，超出了系统本身的承载能力，这时要保证承载能力范围内的用户可用。

服务调用监控：在服务调用链路中，如果发生熔断或降级，运维人员应该及时、清晰的知道问题或热点发生在哪里，以便为系统升级做出必要准备。

上述功能在spring cloud 的 Hystrix 中有较完善的实现，Legendshop微服务版中已经在相应的服务逻辑中都已经做了相应的适配。

四、 灵活网关

微笑服务的服务之上是有一层gateway的，通过gateway服务才能被调用到，这使得企业可以通过gateway组织自己的“中台”系统，即根据实际业务暴露前端需要的api，根据业务场景在gateway中组织不同的权限拦策略，面其背后的服务能力是可重用的，和变化较小的。

五、 总结

综上所述，微服务不是银弹，他有很多好处，但不能一下子解决企业的所有问题，我们对客户的建议是：

要看自已的团队是否适合，团队对SOA开发有清醒的认识，有SOA开发经验，有devops的经验。

这样才能发挥微服务的价值，否则他可能带来更多的是麻烦。