一搭建自己的微服务项目

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的微服务框架。

微服务项目构建标准文档相关推荐

javaee 中文帮助文档_大牛耗时三天整理的：微服务+Nginx+Kubernetes实战文档和面试题...
前言十年之前,相信大家掌握了Java EE互联网轻量级框架整合开发 SSM框架SpringMVC+Spring+MyBatis就已经能够轻轻松松找到一份薪资很高的java开发工作了,而如今只会SSM ...
25岁阿里120W年薪架构师推荐学习的750页微服务架构深度解析文档
前言当前,微服务架构在国内正处于蓬勃发展的阶段,无论是大型互联网公司还是传统的IT企业,纷纷采用微服务架构构建系统. 在过去几年里,DevOps.云原生.面向演进式架构等理念已经深入人心,围绕微服务 ...
超全，看完这份微服务架构与实践文档，微服务不再难
前言: 微服务近年来受到了极大的关注并成为趋势,不信的话可以查看 Google Trends. 可以看到从2014年开始人们对它产生了极大的兴趣,随着时间的推移,这一趋势仍在增长. 随着数字化转型的推 ...
SpringCloud微服务项目的api文档聚合
目录原理简介在网关中配置好路由 Spring Cloud Gatway + Springfox 第一步.在各项目里配置Springfox 第二步.在网关中编写api文档资源路径注意 Spring ...
springcloud feign 服务调用其他服务_springCloud微服务项目构建公共的feign调用
在微服务项目中加入有一个微服务的接口,很多其他的微服务都需要调用它,那么我们可以写在公共的项目中,而不需要每个微服务都建立一个相应的feign 1.先在common 公共项目中建一个公共feign调 ...
微服务调用传string值_springCloud微服务项目构建公共的feign调用
在微服务项目中加入有一个微服务的接口,很多其他的微服务都需要调用它,那么我们可以写在公共的项目中,而不需要每个微服务都建立一个相应的feign 1.先在common 公共项目中建一个公共feign调 ...
华为18级大牛倾情奉送：分布式服务框架和微服务设计原理实战文档，啃完发现涨薪如此简单
前言分布式服务框架不仅仅包含核心的运行时类库,还包括服务划分原则.服务化最佳实践.服务治理.服务监控.服务开发框架等,它是一套完整的解决方案,用来协助应用做服务化改造,以及指导用户如何构建适合自己业 ...
系统部署文档_惊喜！Alibaba架构师终于发布“微服务架构与实践”文档
前言: 对于微服务架构的概念,相信大家应该都不陌生,无论使用 Apache Dubbo.还是 Spring Cloud,都可以去尝试微服务,把复杂而庞大的业务系统拆分成一些更小粒度且独立部署的 Res ...
SpringBoot微服务项目构建war包部署排除指定jar
文章目录一.构建war包部署SpringBoot项目二.构建war包 2.1. 适用范围 2.2. 构建war包三.部署排除指定jar 3.1. 下载排除插件 3.2. 搜索部署排除指定jar ...

微服务项目构建标准文档

一搭建自己的微服务项目

Srping Boot和Srping Could简介

1.5.2 社区活跃度

1.5.3 架构完整度

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

微服务项目构建标准文档相关推荐

最新文章

热门文章

微服务项目构建标准文档

一 搭建自己的微服务项目

Srping Boot和Srping Could简介

1.5.2 社区活跃度

1.5.3 架构完整度

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

微服务项目构建标准文档相关推荐

最新文章

热门文章

一搭建自己的微服务项目