微服务项目构建标准文档

一    搭建自己的微服务项目

 

1.1.1  搭建一个基于Spring Boot框架 的Maven子项目

我们在微服务架构上选择的是maven的父子项目，父项目的名称是cloud。

点击cloud  --> 右键选择new --> other --> 输入maven --> 选择Maven Module -->点击next,如下图所示

点击next进入下一个界面，一定要将复选框勾选中，在Module Name中输入要创建的微服务项目名即可。

点击下一步，在packaging选项中选择jar，而不是war，部署的时候我们是以jar包的形式部署微服务，点击Finish，

这样，一个简单的Maven子项目就搭建完成了。

 

 

再来看看could项目的pom.xml,这里面引入了Spring Boot相关Jar包，因为service-test子项目继承了cloud，所以service-test项目也引用了Spring Boot相关Jar包，具体Spring Boot的jar包参考could的pom.xml。

这样，service-test微服务项目是一个基于Spring Boot框架的Maven子项目。

 

注意事项: 在service-test项目pom.xml中，需要引入一个关于spring Boot的依赖，添加如下代码就可以了。

 

然后在src目录下新建一个BootApplication.java 文件,在class上加上

@SpringBootApplication注解，在main方法中，写上

SpringApplication.run(BootApplication.class,args);

以run as Java Application 的方式运行程序，这样简单的一个Spring Boot程序就运行起来了。

 

1.1.2 如何成为一个服务

  上面只是一个初步搭建基于Spring Boot框架的maven项目，那么如何使该项目成为一个微服务呢？ 其实很简单，只需要下面两个步骤即可。第一步，在BootApplication中添加一个SpringCould注解，@EnableEurakeClient。第二步，

创建bootstrap.yml文件，添加相关配置即可(参考1.5.3中bootstrap.yml文件)

 

 

 

1.1.3 项目搭建注意事项

随着公司的微服务的项目越来越多，在这里，我们对项目的构建做了统一的规范。从项目的命名、项目的包层次结构及配置文件三个方面进行介绍。

 

项目的命名:service-xxx

如: service-ehr、service-crm等等

 

项目的包名: 以公司+项目为基础包名,com.ceway.xxx

          如: com.ceway.ehr  com.ceway.crm等等

  

子包命名规范,以crm项目为例子

   com

ceway

crm

    conf   -->        数据库连接池（因使用了配置服务器，必须有）

    model  -->        实体类

    controller  -->   接口访问层

    mapper -->        数据库访问层

    service    -->    业务处理层

       impl   -->    业务处理实现类

    util   -->        工具类

    vo     -->        表现层对象

   

 

logback.xml文件注意事项

将service-crm替换自己的微服务项目名。

 

 

bootstrap.yml 文件介绍

文件名一定叫bootstrap.yml而不是application.yml。

 

Srping Boot和Srping Could简介

1.2.1  Spring Boot 特性

a) 快速构建独立Spring应用程序。

 

b) 嵌入式Tomcat，Jetty容器，无需部署WAR包。

 

c) 简化Maven及Gradle配置。

 

d) 尽可能的自动化配置Spring，无代码生成和xml配置。

 

e) 直接植入产品环境下的实用功能，比如度量指标、健康检查及扩展配等。

   

f) 对主流开发框架和工具链做无配置集成。

 

 

1.2.2  Spring Boot 优缺点

   优点:

a) 解决配置繁琐的问题，最大化的实现convention over configuration(约定大于配置)。

 

    b)  springboot 要解决的问题, 精简配置是一方面, 另外一方面是非常方便的让spring生态圈和其他工具链整合(比如redis, email, elecsearch)

 

    缺点:

a)  要有spring体系，不然上手困难。

 

b)  版本迭代速度太快。

 

 

1.2.3 Spring Could介绍

Spring Cloud是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

 

 

1.2.4 Spring Could 子项目

a)  Spring Cloud Config：配置管理开发工具包，可以让你把配置放到远程服务器，目前支持本地存储、Git以及Subversion。

 

b)  Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。

 

c)  Netflix Eureka：微服务注册发现，一个基于 REST 的服务，用于定位服务，以实现云端的负载均衡和中间层服务器的故障转移。

 

d)  Netflix Hystrix：断路器（熔断），旨在通过控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。

 

e)  Netflix Zuul：API网关，是提供动态路由，监控，弹性，安全等的边缘服务。

 

f)  Spring Cloud Sleuth：日志收集工具包，封装了Dapper,Zipkin和HTrace操作。

 

g)  Spring Cloud Data Flow：大数据操作工具，通过命令行方式操作数据流。

 

h)  Netflix Ribbon: 负载均衡组件，微服务之间的调用

 

i)  Netflix Feign: 微服务之间REST API调用方式

 

j)  Spring Cloud Security：安全工具包，为你的应用程序添加安全控制，主要是指OAuth2。

 

k)  Spring Cloud Stream：数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。

 

l)  Spring Cloud CLI：基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。

 

标红的SpringCould子项目，已经在我们自己搭建的微服务中应用上了。

 

微服务概述

 

第一章: 微服务

1.3  微服务概述

 

1.3.1  什么是微服务

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

尽管“微服务”这种架构风格没有精确的定义，但其具有一些共同的特性，如围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的“去集中化”控制等等。微服务架构的思考是从与整体应用对比而产生的。

 

 

1.3.2 微服务架构通用特性

a) 通过服务实现应用的组件化(Componentizationvia Services)：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。

   

b) 围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的

 

c) 产品而非项目模式(Productsnot Projects)：传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。

 

d) 智能端点与管道扁平化(Smartendpoints and dumb pipes)：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。

 

e) “去中心化”治理(DecentralizedGovernance)：整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。

 

f) “去中心化”数据管理(DecentralizedData Management)：微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。

 

g) 基础设施自动化(InfrastructureAutomation)：云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。

 

h) 演进式的设计(EvolutionaryDesign)：微服务应用更注重快速更新，因此系统的计会随时间不断变化及演进。微服务的设计受业务功能的生命周期等因素影响。如某应用是整体式应用，但逐渐朝微应用架构方向演进，整体式应用仍是核心，但新功能将使用应用所提供的API构建。再如在某微服务应用中，可替代性模块化设计的基本原则，在实施后发现某两个微服务经常必须同时更新，则这很可能意味着应将其合并为一个微服务。

 

 

1.3.3 微服务优点

a)  每个服务都比较简单，只关注于一个业务功能。

b)  微服务架构方式是松耦合的，可以提供更高的灵活性。

c)  微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。

d)  每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。

e)  微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。

 

 

1.4   为什么需要微服务

 

1.4.1 传统IT面临的问题

a) 使用传统的整体式架构(Monolithic Architecture)应用开发系统，如CRM、ERP等大型应用，随着新需求的不断增加，企业更新和修复大型整体式应用变得越来越困难。

   

b) 随着移动互联网的发展，企业被迫将其应用迁移至现代化UI界面架构以便能兼容移动设备，这要求企业能实现应用功能的快速上线。

 

c) 许多企业在SOA投资中得到的回报有限，SOA可以通过标准化服务接口实现能力的重用，但对于快速变化的需求，受到整体式应用的限制，有时候显得力不从心。

 

d) 随着应用云化的日益普及，生于云端的应用具有与传统IT不同的技术基因和开发运维模式。  

 

 

1.4.2  技术上的支持

a) 互联网/内联网/网络更加成熟。

 

b) 轻量级运行时技术的出现(node.js, WAS Liberty等)。

 

c)  新的轻量级协议(RESTful API接口, 轻量级消息机制)。

 

d) 简化的基础设施：操作系统虚拟化(hypervisors), 容器化(e.g. Docker), 基础设施即服务 (IaaS), 工作负载虚拟化(Kubernetes,Spark…)等。

 

e) 服务平台化(PaaS)： 云服务平台上具有自动缩放、工作负载管理、SLA 管理、消息机制、缓存、构建管理等各种按需使用的服务。

 

 

1.5   微服务框架

当前业界比较成熟的微服务框架有Spring的Spring Boot/Cloud，阿里的Dubbo等。

 

 

1.5.1背景

         Dubbo，是阿里巴巴服务化治理的核心框架，并被广泛应用于阿里巴巴集团的各成员站点。阿里巴巴近几年对开源社区的贡献不论在国内还是国外都是引人注目的，比如：JStorm捐赠给Apache并加入Apache基金会等，为中国互联网人争足了面子，使得阿里巴巴在国人眼里已经从电商升级为一家科技公司了。

Spring Cloud，从命名我们就可以知道，它是Spring Source的产物，Spring社区的强大背书可以说是Java企业界最有影响力的组织了，除了Spring Source之外，还有Pivotal和Netfix是其强大的后盾与技术输出。其中Netflix开源的整套微服务架构套件是Spring Cloud的核心。

 

 

1.5.2 社区活跃度

我们选择一个开源框架，社区的活跃度是我们极为关注的一个要点。社区越活跃，解决问题的速度越快，框架也会越来越完善，不然当我们碰到问题，就不得不自己解决。而对于团队来说，也就意味着我们不得不自己去维护框架的源码，这对于团队来说也将会是一个很大的负担。(Dubbo已不再更新和维护，SpringCloud持续更新维护)

 

 

1.5.3 架构完整度

或许很多人会说Spring Cloud和Dubbo的对比有点不公平，Dubbo只是实现了服务治理，而Spring Cloud下面有17个子项目（可能还会新增）分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo只是Spring Cloud Netflix中的一个子集。但是在选择框架上，方案完整度恰恰是一个需要重点关注的内容。

虽然该架构相较于单体架构有模块化解耦、可独立部署、技术多样性等诸多优点，但是由于分布式环境下解耦，也带出了不少测试与运维复杂度。

根据微服务架构在各方面的要素，看看Spring Cloud和Dubbo都提供了哪些支持。

 

      小结：Dubbo实现了服务治理的基础，但是要完成一个完备的微服务架构，还需要在各环节去扩展和完善以保证集群的健康，以减轻开发、测试以及运维各个环节上增加出来的压力，这样才能让各环节人员真正的专注于业务逻辑。而Spring Cloud依然发扬了Spring Source整合一切的作风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简单配置、快速开发、轻松部署的特点，让原本复杂的架构工作变得相对容易上手一些。所以，如果选择Dubbo请务必在各个环节做好整套解决方案的准备，不然很可能随着服务数量的增长，整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud，相对来说每个环节都已经有了对应的组件支持，可能有些也不一定能满足你所有的需求，但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。

总结: 综合其框架背景、社区活跃度、架构完整度及文档质量，我们的团队决定采用Spring Boot + Spring Could的微服务框架。