微服务架构的核心问题

背景

工作多年，作为后端开发，经历了几家公司，每家公司都有自己核心的一些技术栈，去到不同的公司自己的学习技术的和实践技术的着重点可能不同，最近想把以前学习到的用到的技术做一个分类总结。首先我想从第一家公司技术栈讲起：springcloud，因为我们是做医药电商，公司内部需要将整个电商中台进行微服务改造。

首先将不同的服务模块化，订单中心，用户中心，物流中心，商品中心，报表中心等分别抽出来模块话开发，代码没有变化。

微服务架构的4个核心问题：

1、服务很多，客户端该怎么访问？
2、这么多服务，服务之间如何通信？
3、这么多服务，如何治理？
4、服务挂了怎么办？

解决方案：

Spring Cloud 生态

1. Spring Cloud NetFlix。一站式解决方案，能解决上述四个问题
   问题一解决：api网关，用到zuul组件
   问题二解决：Feign ------基于HttpClient-----http通信方式， 同步并阻塞
   问题三解决： 服务注册发现：Eureka
   熔断机制：Hystrix
   。。。。
2. Apach Dubbo Zookeeper 半自动，需要整合别人的
   API没有 找第三方组建，或者自己实现的
   dubbo：rpc
   服务注册中心：zookeeper
   其他的没有可以借助三方的，比如：Hystrix
   dubbo这个方案不完善，专一的prc框架
3. Spring Cloud Alibaba 最新的一站式解决方案，更简单
   与 Spring Cloud NetFlix类似，

不管哪种方案万变不离其宗：
1、路由-API
2、通信-http、rpc
3、服务注册与发现
4、熔断机制

这些解决的核心就是因为网络不可靠。

微服务优缺点

优点：

• 单一职责原则
• 每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或者需求
• 开发简单，开发效率提高，一个服务可能就是专一的只干一件事情
• 微服务能够被小团队单独开发
• 微服务是松耦合，是有功能意义的服务，无论是开发阶段或者部署阶段都是独立的
• 微服务能使用不同的语言开发
• 容易和三方集成，微服务容易且灵活的的方式自动部署，通过集成工具，如jenkins等。
• 微服务容易被一个开发人员理解
• 微服务允许你利用融合新的技术
• 微服务只是业务逻辑代码，不会和html。css。或者其他界面混合
• 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库

缺点：

• 开发人员要处理分布式系统的复杂性
• 多服务运维难度，随着服务的增加，运维的压力也在增大
• 系统部署依赖
• 服务间通信成本
• 数据一致性
• 系统集成测试
• 性能监控

技术选型

选型依据

• 整体解决方案和 框架成熟度
• 社区热度
• 可维护性
• 学习曲线