==> 学习汇总（持续更新）
==> 从零搭建后端基础设施系列（一）-- 背景介绍
-
什么是服务发现？
服务发现是指使用一个注册中心来记录分布式系统中的全部服务的信息，以便其他服务能够快速的找到这些已注册的服务。 ---- 百度百科
-
什么是服务治理？
服务治理（SOA governance），按照Anne Thomas Manes的定义是：企业为了确保事情顺利完成而实施的过程，包括最佳实践、架构原则、治理规程、规律以及其他决定性的因素。服务治理指的是用来管理SOA的采用和实现的过程。 ---- 摘之知乎某回答
这个说得就比较专业，我用大白话说一下，所谓的SOA，就是将几十上百万个微服务统一管理起来，做到有效的监控。精简点就是管理监控，这是精髓。因为服务太多，机器太多，导致SOA的解决方案非常复杂，所以才会让人觉得这个东东只可远观，不能近玩。
-
为什么需要服务发现与治理？
如果看过从零搭建后端基础设施系列，那么也许你就会知道,代码里面连接别的服务的时候，都是手动把IP，端口写死的。单机测试还好说，如果是分布式的微服务，那么机器是随时可能扩容、缩容的，所以IP也是变化的。那么问题是不是已经很明显了？可能有的同学还不是很清楚，那么我举个小例子。
假设- 有A、B、C服务
- A依赖于B，B依赖于C
- 每个服务都部署在多机房，多机器上（通俗点说就是，每个服务都在多台机器上运行，这些机器呢又分布在不同的地方）
此时，如果C服务的1号机器挂了，但是呢B的某台机器是通过固定IP来连接这台服务器的话，那么B服务的这个节点是不是相当于也挂了？同理A的某个节点也挂了。但是如果采用了服务发现（也就是服务注册中心），就可以事先将某个服务的信息存储起来，然后有个唯一标识，当服务运行的时候，自动上报该服务的唯一标识与机器信息，这样，任意一台机器，只需要提供唯一标识，即可拿到对应服务的可用机器列表，任意连接一台即可！来个简单的图示：
可以看到，每个服务只需要向注册中心请求某个服务的机器列表即可，不再需要将IP写死，非常的灵活。而且注册中心还会实时的去监测机器的运行状态，如果某个机器挂了，会立即从机器列表中摘除，就不会再有流量打过去了。 -
服务注册中心与服务治理应该是个什么关系？
就功能划分来讲，这两个是有区分的，前者是管理服务的信息，确保每个服务都有唯一的身份证，它不负责机器的管理。后者是管理机器信息，监控每个机器的状态，并且需要拿到注册中心的服务信息，与这些机器相关联起来。做到任意一台机器出现了问题，能快速定位到服务以及服务负责人等。 -
服务注册中心设计思路
注意注意，本系列的所有服务开发，仅仅算上是demo级别，用来学习这些大家伙的思想的，请勿将代码用于实际项目中，否则就回家种田拉！-
如何唯一标识一个服务
我这里使用类似maven的group-id来唯一标识，取名为appKey，例如appKey=com.acme.thrfit.server appKey=com.acme.web.server -
注册需要哪些信息
正常来说，需要挺多的，反正越详细越好，就像办理身份证，要填很多信息一样。这里因为是demo，所以只需要appKey、serviceName和manager即可。 -
使用什么架构
正常来说，用户是通过网页去填信息，然后注册的，这里没有前端，所以只能通过postman调http接口，所以肯定得有web层，然后别的后端服务调的时候，是通过http呢，还是thrift？个人觉得thrift会更好，rpc肯定比http要更快，特别是在这种延迟要求较低的场景。所以就确定下来了，服务注册中心服务，既提供http接口，也提供thrift接口，相当于把前面的thrift-server和web-server结合起来
-
-
服务治理设计思路
这个一开始先做个最简单的例子，后面逐步加东西（服务治理这东西太大，一口吃不成大胖子）。- 如何拿到服务运行所在机器的信息
这个其实挺简单的，只需定个规则，让所有服务启动时，都调用它的某个接口，上报机器信息即可。 - 如何检测机器运行状态
这个也简单，跟所有的机器，维持一个心跳，如果停止了，就立马摘除这台机器节点。（如果机器太多了，实现起来挺复杂的，也不知道是主动检测好，还是被动检测好，水平有限~，继续思考ing）
目前只需要解决这两个问题，就可以让这个demo跑起来了。
- 如何拿到服务运行所在机器的信息
-
小结
还有很多细节，还是等实际coding后，再将问题抛出，下一篇就会将代码献上，并且分析其中的细节，以及后续需要改进的点。
博客专家