微服务 /DDD - 第十周总结

超大型单体应用存在的问题

• 编译、部署困难：源代码过于庞大

• 代码分支管理困难：功能开发过于交叉，导致合并代码冲突

• 数据库连接池耗尽：分布式部署越多消耗越多

• 新增业务困难



解决方案就是拆分，将模块独立部署，降低系统耦合性：

• 纵向拆分：将一个大应用拆分为多个小应用，如果新增业务比较独立，那么就直接将其设计部署为一个独立的web应用系统。

• 横向拆分：将复用的业务独立拆分出来，独立部署为微服务，新增业务只需要调用这些微服务即可。



微服务框架需求

• 失效转移

对于大型网站的微服务而言，即使是很少访问的简单服务，也需要集群部署，同时微服务框架还需要支持服务提供者的失效转移机制，以实现服务高可用。

• 负载均衡

对于集群部署的服务提供者,服务请求者可以使用加权轮询等手段访问，使服务提供者集群实现负载均衡。

• 高效的远程通信

对于大型网站，核心服务每天的调用次数会达到数以亿计，如果没有高效的远程通信手段，服务调用可能会成为整个系统性能的瓶颈。

• 对应用最少入侵

网站技术是为业务服务的，是否使用微服务需要根据业务发展规划，微服务也需要渐进式的演化，甚至会出现反复，即使用了微服务后又退回到集中式部署，微服务框架需要支持这种渐进式演化和反复。当然服务模块本身需要支持可集中式部署，也可分布式部署。

• 版本管理

为了应对快速变化的需求，服务版本升级不可避免，如果仅仅是服务实现升级，那么这种升级对服务请求者而言是透明的，无需关注。但是如果服务的访问接口发生变化，就需要服务请求者和服务提供者同时升级才不会导致服务调用失败。企业应用系统可以申请停机维护，同时升级接口，而网站服务不可能中断，需要服务提供者先升级接口，并同时提供历史版本的服务请求者调用，当请求者访问接口升级后才可以关闭历史版本服务。



微服务架构落地

• 业务先行，先理顺业务边界和依赖，技术是手段而不是目的。

• 现有独立的模块，后有分布式的服务。

• 业务耦合严重，逻辑复杂多变的系统进行服务重构要谨慎。

• 要搞清楚实施微服务的目的是什么，业务复用？开发边界清晰？分布式集群性能提升？ 最终要的是为需求服务。



微服务核心问题

1. 服务注册与发现

2. 负载均衡

微服务部署后向注册中心注册，调用者通过注册中心获取服务列表，通过负载均衡算法选取一台进行微服务调用，调用者和微服务通过注册中心隔离，这样微服务增加与删除都不需要主动通知调用者。



微服务网关

微服务网关代替调用者与注册中心交互，调用者直接和网关通信，网关负载转发请求。



网关作用

• 统一接入

• 安全防护

• 限流管控与容错

• 协议适配