1. 目前单体服务的痛点

  • 很多人维护一个单块应用，频繁的进行代码合并，频繁的解决代码冲突，解决冲突的时间和成本很高的，导致开发效率低下
  • 每次上线都要跟最新代码进行合并，需要重新进行全量功能的回归测试（经常出现仅测试本次迭代更改代码，出现部分功能点漏测的情况），很多代码都可能给有变动，必须全量回归测试，耗费时间很多，开发效率低下。
  • 多人频繁上线，你等我，我等你，互相协调困难，而且可能会出现别人多次先上线，你多次重复的合并代码，解决冲突，全量回归测试，做很多次重复的事情，导致效率低下
  • 测试服务器少，部分问题因为没有人测，到线上才发现

    2.微服务架构生态组件

    经过调查了解到，微服务主要组件包含但不限于以下内容：
    注册中心、RPC框架、多环境隔离、自动化部署、分布式事务、限流/熔断/降级、配置中心、监控中心、链路监控、日志中心、API网关、安全认证、服务治理
    百度自用CRM这边 基本使用spring cloud相关组件
    早期的spring cloud 微服务体系的组件，是以 eureka（注册中心），feign+ribbon（rpc），zuul（网关），hystrix（熔断限流），用zipkin和sleuth做链路监控，stream做消息中间件集成，contract做契约测试支持，
    目前了解到自用这边，使用consul（注册中心），feign+ribbon（rpc），自研网关，ELK（日志中心）

    3.国内外公司微服务架构生态组件对比

    最近一年多，阿里的dubbo重启活跃维护，
    同时阿里把自己的微服务技术栈融入进了spring cloud体系和标准，
    形成了一个spring cloud alibaba微服务技术组件，也就是以nacos、dubbo、seata、sentinal、rocketmq等技术为核心的一套技术体系

注册中心：nacos -> eureka
RPC框架：dubbo -> feign+ribbon
分布式事务：seata -> 无
限流/熔断/降级：sentinel -> hystrix
API网关：无 -> zuul

4、如何进行微服务拆分

往大了说，可以基于领域驱动模型的设计，往小了说，可以基于功能模块进行拆分。根据功能拆分成多个子模块，如何系统更复杂了，可以继续分拆。
结合实际情况来说这个问题。比如idata如何进行拆分，个人感觉先根据功能模块拆分，可以在面试前提前画好架构图，结合一些知识，描述出自己的想法。这块肯定也是要做好知识储备的。在不断的面试中去优化自己的一些设计内容等。