前言
首先本文不讨论为什么要服务化，包括服务化的优点缺点。
其次本文也不讨论什么是微服务，也不讨论微服务和SOA的区别。
最后本文也不讨论哪个技术最优。
服务框架构成
最基本的服务框架
基本的服务化框架包括如下模块：统一的RPC框架，服务注册中心，管理平台。
有了这三个模块，就能实现基本的服务化。下面对三个模块进行具体分析。
RPC框架选型
为什么一定要是统一的RPC框架，而不是随便啥框架，这里主要是为了技术对齐，减少开发人员的学习成本，减少团队间沟通成本。
好，那么选择一个RPC框架，我们都需要考量什么东西呢？这里我总结下：
- 代码规范：例如是对已有代码透明，还是代码生成。
- 通讯协议：例如是TCP还是HTTP
- 序列化协议：例如是二进制还是文本，是否需要跨语言，性能
- IO模型：异步/同步，阻塞/非阻塞
- 负载均衡：客户端软负载，代理模式，服务端负载
另外如果是从开源里面选择，那么我们还需要考量：
- 成熟度：包括学习成本，社区热度，文档数，是否有团队维护，稳定性（盲目追求的不一定是最适合）
- 可扩展性：是否有SPI支持扩展，是否支持上下兼容
- 跨语言：是否支持跨语言
- 性能：要想作为RPC框架，性能一般都不会太差 [滑稽脸]
下面是常见的一些开源框架的比较，大家可以看一下。
Ps：SOAP，RMI，Hessian，ICE就不列举了。
选型小结：
- 如果需要与前端交互的，适合短链接、跨语言的RPC框架，例如RESTful、gRPC等
- 如果纯粹后台交互的，适合长链接、序列化为二进制的RPC框架，例如thrift、dubbo等更高效
- 如果是小公司，新公司从头开始推广服务化框架的，可以选择规范化的RPC框架，例如thrift、RESTful、gRPC
- 如果是已有大量业务代码的再推广服务框架的，那么最好选择无代码入侵的RPC框架，例如dubbo、RESTful
注册中心选型
注册中心相当于是服务提供者和服务调用者之间的引路人，在服务治理中的作用极为重要。
选择注册中心基本要考量：
- 服务注册：接收注册信息的方式
- 服务订阅：返回订阅信息的方式，推还是拉
- 状态检测：检测服务端存活状态
重点提一下这个状态检测，因为这个要是检测不准确会误判，导致严重后果，
例如Zookeeper根据服务端注册的临时节点进行状态检测，如果服务端和Zookeeper之间的网络闪断，导致Zookeeper认为服务端已经死了，从而摘掉这个节点。
但是其实客户端和服务端直接的网络是好的，这样就有可能把节点全部摘掉，导致无可用节点。
如果是从开源里面选择，那么还需要考量：
- 成熟度：包括学习成本，社区热度，文档数（盲目追求的不一定是最适合）
- 维护成本：注册中心维护
- 数据解构：是否能快速定位结果，是否能遍历
- 性能和稳定性：
- CAP原则：CP（关注一致性）还是AP（关注可用性）
下面是常见的一些使用开源项目做注册中心的比较，大家可以看一下。
Ps：Redis和MySQL没有列举。
选型小结：
- 规模小选择CP，RPC框架可以直接接入数据源
- 规模大选择AP， RPC框架不可以直接接入数据源
- 存在跨机房，跨地域的尽量不要选有强一致性协议的注册中心
- RPC框架必须要有注册中心不可用的容灾策略
- 服务状态检测十分重要
简易管理端
管理端没啥特殊要求，最起码能看到服务提供者和调用者即可。
完善的服务化框架
如果需要一个完善的服务化框架，那么必须增加外部模块，常见的模块如下图：
接口文档管理
提供一个接口文档管理以及接口查询的入口，可以是一个公共的WIKI，也可以是独立的系统，等等。
这里可以定义接口的文档，包括接口描述，方法定义，字段定义
可以定义接口的SLA，包括支持的并发数，tp99多少，建议配置是什么