如何开发微服务

如何开发一个微服务架构的系统

在上一篇文章中，我们分析了微服务的由来以及微服务所具备的一些共同特征。张三曾说过"知易行难"，那么在了解了什么是微服务之后，我们应当如何来构建一个微服务系统呢？基于上一篇提到的微服务的一些特征，在这篇文章中，我们来分析一下。

一、注册中心

在单体应用中，我们几乎可以不考虑程序间的调用问题，但是在微服务的架构中，每一个服务的数量、甚至网络地址都是可以随时动态变化的。这时传统的服务间调用方式已经无法适应微服务的架构，必须有一个组件来对微服务进行管理，且其对外提供统一接口，使得调用方可以根据被调用的服务的标识（如服务名）来直接进行服务调用，而无需关注被调用服务的地址变化。

这里我们可以看出注册中心要解决的核心问题：
1、服务注册
对外提供接口，可以实现服务信息的注册。
2、服务发现
对外提供接口，可以根据服务标识来获取到服务信息

二、配置中心

在单体应用中，关于一些配置项一般都会建立一个.conf文件进行管理。这在单体应用的场景下开发简单且易用，但是在微服务的架构中，随着服务数量的增加，当我们需要对一些配置项进行更改时就会发现，每一个配置项的改动都会涉及到几个甚至十几个服务器配置的变更。这带来了极大的不可靠性，没有人能够保证每一次的修改是正确的，且对运维也带来了很大的挑战。
所以在微服务中，我们有必要将配置统一管理起来。

那么配置中心要解决的问题就是：
1、应用配置信息的统一管理：包括写入、查询、修改、删除。

三、网关

微服务将原有的单体应用拆分成多个应用，这意味着我们每个微服务要考虑安全验证、限流、还有可能存在的跨域问题。而且由于对外暴露导致内部重构的代价很高。
这显然是不合理的。
所以我们需要一个总的接口来处理这些事情，使我们整个微服务对外展示为一个整体，一定意义上讲，达到了“高内聚，低耦合”。这可以使得业务应用专注于自己功能的实现。

所以网关要实现以下功能：
1、作为微服务的统一入口，选择后端服务进行请求的分发
2、安全验证，校验请求合法性
3、负载均衡
4、限流

至此，我们可以认为一个微服务的架构已经出来了，看个图

但是一个微服务应该有多大？我们如何确定服务的大小？

这是一个难以描述的问题，没有人可以告诉你你的微服务应该设计成多大，但是我们还是可以从服务的演化中来看一看，是否可以找到一些感觉。微服务要解决什么问题呢？
因为日益臃肿的单体服务，可维护性差，无法扩展，研发周期长，无法承担不断增长的业务量。 这样来看，可以从以下几个角度来看你设计的微服务大小是否合适：
1、根据业务划分，横向可扩展
2、功能高度内聚，但从一定角度来说能独立解决问题
3、一个微服务团队，核心开发人员或许不应当超过10~12人。

之后的文章我们来讨论微服务的具体实现技术，这里先来总结一下我们目前看到的在实现我们的具体业务前，需要关注并实现的模块。
1、注册中心：实现服务的注册于发现
2、配置中心：实现配置的统一管理
3、网关：实现统一入口、路由、负载均衡、安全验证、限流。