微服务如何划分？

基于业务复杂度来划分微服务，中、高复杂度选择领域驱动，低复杂度选择数据驱动。同时考虑团队对领域的熟悉程度，当然复杂度非常高时，及时不熟悉，也需要通过学习实践的方式掌握。个人倾向于领域驱动来做微服务的划分，特别是TOB的企业系统的复杂度都不低。

数据驱动是自下而上的架构设计方法，强调数据结构，也就是通过分析需求，确定整体数据结构，根据表之间的关系划分服务。具体步骤如下：通过领域专家分析需求，出原型，团队讨论到满意为止；抽象数据结构；划分服务；确定服务调用关系；业务流程验证（成本、性能等）；持续优化。

领域驱动是自上而下的架构设计方法，通过与领域专家建立统一的语言，不断交流，确定关键业务场景，逐步确定边界上下文。具体步骤如下：通过模型和领域专家建立统一语言；业务分析，确定核心流程然后扩展到全部；寻找聚合，显示的定义领域模型的边界（事件风景）；确定服务的调用关系；业务流程验证；持续优化；

单体到微服务：提供公共的基础服务（单点登录）；垂直划分，不断从单体中抽象出服务；APIGateway承担太多职责，成为瓶颈，需要水平拆分（拆成详情页、下单等）；

微服务的拆分原则：优先抽象通用服务；优先抽象比较容易识别的，边界比较明显的服务；优先抽象核心服务；优先抽象独立属性的服务；绞杀者模式逐渐替换老服务（需要考虑如何灰度发布、迁移数据、服务不中断等）；

微服划分的反模式：根据代码行数划分（大服务也有正常合理的场景，不要额外增加复杂度）；划分粒度越小越好（最好根据团队规模划分）；一次性划分服务（先拆业务代码再拆数据库或业务代码或数据库同时拆，第一种可以过渡，最终还是第二种）；服务拆分一旦完成，不能改变（重新划分或合并都是有可能的，以领域或团队为基本划分原则）；先实施组件化，再实施微服务架构（优先领域垂直划分再抽象组件或基础服务进行水平划分）；

微服务API设计原则？

核心原则：简单（正常思维）；易懂（可读性，最好不需要文档）；一致（统一规则）；稳定（不要轻易改变，通过新增版本区分）；安全（鉴权、限流、熔断、明示错误码）；

服务间通信-RPC：影响RPC性能的有几个方面的因素：序列化（Thrift、Protobuf、Avro、Kryo、Jackson）、传输协议（HTTP、Socket、TCP、UDP）、连接（长连接、短连接）、IO模型（同步阻塞、同步非阻塞、多路复用、异步）。

服务间通信-Restful：架构包括协议、域名、版本、路径、方法、参数、编码、状态码；约束条件：单一职责、幂等性、无状态、客户端发起、原子性、易用、SLA。可以使用Swagger实现。

Http2：基于二进制协议，相比Http1.X文本协议，性能更高；多路复用，提高性能；Http1.X是开启Connection：keep-alive保持长连接，客户端请求服务端响应，一直给服务端发心跳，也不能用来推送，Http2引入了推送模式，即服务端向客户端发送数据，一次请求可以发送多次响应，但客户端缓存的情况下，可能存在性能问题，可以通过Server Hint来解决。

gRPC：HTTP2和Protobuf的结合，标准的通信，基于流模型处理，提升处理效率。相比于TCP的性能上还是有显著的差距。

微服务框架有哪些重要功能？

服务治理：服务的爆炸增长，比如成千上万时，如何管理？

容量规划：设计最大容量，洪峰策略，隔离关键服务，控制版本，对服务升级，优雅降级。

高效通信：需要实现高效的序列化、反序例化、以持并行、异步、非阻塞转换、支持多语言。

负载均衡：软硬件负载均衡、故障转移、流理切换。

框架示例：

Dubbo（Provider提供者、Consumer（消费者）、Registy（注册中心，服务的注册和发现）、Monitor（监控，调用次数和时间等））；

Spring Cloud：Config（配置管理工具）、Netflix（Netflix微服务相关套件）、Cluster（选举算法服务）、Consul（服务注册中心）、ZooKeeper（服务注册中心）、Security（安全工具包）、Sleuth（匹配ELK的服务调用链跟踪）、Data Flow（数据处理）、Stream（适配Kafka消息中间件框架）、Task（定时任务框架）等等。

Zookeeper和Etcd服务发现组件：Etcd是一个高可用的键值存储系统，主要是用于共享配置和服务发现，Go语言编写，通过Raft一致性算法处理日志复制以保证强一致性。Zookeeper为大型分布式计算提供开源的分布式配置服务、同步服务、命名注册。Zookeeper不一定高可用，它是通过Paxo来保证一致性，也就是参议员投票机制。

微服务的部署策略：采取服务独享数据库的方式部署；服务独享虚拟机/容器，共享是比较传统的模式，包括一个物理机部署多个服务（进程级隔离）、一个虚拟机部署多个服务（进程级隔离）、一个系统容器（Docker等）部署多个服务（进程级隔离）、一个应用容器（apache、Tomcat）部署多个服务（非进程级隔离），共享节省资源，隔离性差，服务共享虚拟机/容器是指一个虚拟机或容器中只部署一个服务，优点是隔离性好，生成一个镜像部署容易，发布快，缺点是资源利用率不高。