针对传统的单体应用，它在以下方面存在问题：
- 成本方面，对于单体服务在服务器硬件方面的成本，我们需要特别注意异构工作负载和不同保障级别的问题。
- 保障级别，研发效率是我们能够高效工作的基本保障，我们必须主语单体服务导致的串行编译、测试和发布，以及研发团队只能单一的研发语言和生态。
- 稳定性问题，一方面，局部风险会放大到全局，一个局部非核心功能的崩溃、死锁等异常情况，都会影响所有业务。另一方面业务迭代周期差异大。
上述三个问题，本质都是因为我们的业务是一个单体应用，不能按照资源类型进行分别扩容，不按功能或者服务进行小范围的部署，也不能按照业务的需求来选择更合适的研发语言和生态等。
服务发现的关键问题
服务发现要解决这样一个问题：如果服务A调用服务B， 那么服务A怎么获取到被调用方B的IP和Portal。
- 最容易想到的方式是配置 IP 和 Port 列表，即直接在服务 A 的配置文件中配置服务 B 的 IP 和 Port，如果服务 B 有多个实例，那么就配置一个列表。
- 我们可以将配置 IP 和 Port 列表的方式修改为配置域名和 Port，即在服务 A 的配置文件中不再配置服务 B 的 IP 和 Port 列表，而是配置服务 B 的域名和 Port。这样可以通过域名解析获得所有服务 B 的 IP 列表，让所有的服务 B 都监听同一个 Port。
服务注册发现需要解决两个关键问题：
- 统一的中介存储：调用方在唯一的地方获得被调用服务的所有实例信息。
- 状态更新与通知：服务实例的信息能够及时灯芯并且通知了服务调用方。
怎么实现服务发现
针对服务发现中使用的存储，它需要具备以下的特点：
- 可用性要求非常高
- 性能要求中等
- 数据容量要求低
- API友好程度
一般来说，etcd、ZooKeeper和Eureka在夜晚都是比较合适的存储系统。
针对服务状态更新，也可以分为几部分：
- 服务状态的更新，即服务注册。
- 服务的状态通知，即服务发现。
我认为 Eureka 之类的 AP 系统更符合要求。因为服务发现是整个分布式系统的基石，所以可用性是最关键的设计目标。并且上面介绍的服务，在同步自己的状态到中介存储，以及调用方通过中介存储区获得服务的状态，这两个过程中的数据同步都是最终一致性的。既然服务注册发现系统整体是一个 AP 系统，那么将中介存储设计为 CP 系统，去放弃部分的可用性是不值得的。
此文章为极客时间4月份Day04学习笔记，内容来自《深入浅出分布式技术原理》课程。
