在提供了微服务的基础设施后,我们可以放手开发各个微服务了。业务服务层是一些“基础微服务”或“业务微服务”,他们“各司其职”,服务之间的耦合应当做到最低。
微服务面向的“用户”,一般是Web、移动端、PC端等。出于用户体验的考量,服务端提供给客户端的的接口应当尽量实现结果聚合,减少请求次数。因此,一般要设置一层接入网关,他负责调用业务微服务A B C等,完成结果聚合后,一并返回给客户端。
对于绝大多数的中小公司,且无强烈的数据保密需求,我强烈建议使用云主机。
前面已经提到,微服务需要借助容器技术才能“顺利启航”。目前主流的方案有:docker加脚本、swarm集群、Kubernetes集群、Marathon集群。选用Kubernetes集群,它内置的功能完全可以满足”容器的监控、调度、管理“。在这里我们采用排除法,说说为什么不选用其他几个方案。
我们选用Java作为开发语言,并使用Spring Boot作为开发框架。Spring Boot作为Spring框架的一次"革命",可以说是为了微服务而生的。
为了简化实现难度,我们将借助Kubernetes内置的服务和虚拟端口功能,来实现服务的注册与发现。换句话说,我们将服务注册与发现的能力,下推一层到运维平台层。对于微服务这一层,服务的注册与发现是完全透明的。熔断与限流:微服务之间的调用链更加复杂,为了降低&隔离服务故障造成的影响,一般选用和熔断或限流策略。我们选用Hystrix作为熔断功能的基础库并进行了封装,Guava的RateLimit作为限流功能的基础库并进行了封装。
这里主要关注配置的自动下发、自动更新和易维护性。我们采用git + cfg4j的模式实现配置中心。