油盐微服务——微服务拆分

适合上微服务么？

不适合上微服务的场景有：

1. 系统包含很多很多强事物的。
2. 访问压力不大，对可用性要求不高的。
3. 业务相对稳定，迭代周期长的。

康威定律：

即沟通的问题会影响系统的设计。当沟通很难的适合，会不自觉的减少沟通，从而影响迭代的速度。
所以微服务提倡小团队，由小团队负责整个系统的设计与实现，团队内部可以具有频繁的细粒度的沟通。

微服务特点

• 由一系列小的服务共同构成
• 单独部署，构建在自己的进程中
• 每个服务用独立的业务开发
• 分布式的管理

服务拆分方法论

• 拆功能
• 拆数据

---

1. 拆功能

• 单一职责，松耦合，高内聚。
• 关注点分离：按职责分离关注点；按通用性分离关注点（通过的功能）；按粒度级别分离关注点。

---

服务和数据的关系：

• 先考虑业务功能，再考虑数据
• 无状态服务：
  状态：如果一个数据需要被多个业务所共享才能完成一个请求，那么这个数据被称为状态。这个业务就叫做有状态服务。
  有状态的业务服务应该改成无状态的业务服务，如下图所示。应该把状态放到后端，就能够将业务服务按需动态伸缩节点，不用考虑缓存数据如何同步的问题。
  

---

2. 拆数据

• 每个服务都有自己的数据存储，只能通过服务提供的API访问服务的数据，而不能通过直接访问数据库来访问数据。
• 依据服务特点选择不同的数据库类型。（比如，类型丰富对事务要求不高，可以选mangoDB，做搜索用ES）
• 针对边界设计API