jq项目如何启服务_为什么是微服务？我该如何规划微服务架构下的项目结构？零起点微服务教程-1...

给这篇文章5分钟，你讲学习到为什么需要微服务架构？微服务架构的技术选型，以及这套教程简单的背景。

为什么是微服务？

从2015年5月微服务概念被提出以来，微服务已经发展了6年，6年里大浪淘沙，微服务最终经受住了时间的考验，从普遍的怀疑到成为现在的主流架构风格。如果说微服务为什么存活了下来，要就要从单体架构为什么死亡说起。 单体架构为什么死亡 单体架构在经过了几十年的发展以后，已经逐渐成熟，同时单体应用的缺点也变的相对明显： 交付时间长：一般一个项目在立项开始就组件搭建单体应用，但是因为并不能根据功能进行拆分，所以只能所有的功能一起上线，这通常是一个很长的周期。 应用臃肿：因为所有的功能都在同一个单体应用里面，所以这个单体应用一般会很大，并显的很臃肿。 没有明确的责任人：单体应用一般由很多人一起维护，所以某一个功能不能指定一个唯一的责任人。一旦事故发生，责任就会发生推诿。 开发相互影响，一挂具挂：单体应用所有人维护一个环境，如果其中一个人的代码出现block流程的重大bug会导致整个环境不能工作，而影响其他人。 * 无法与Devops之间高效的衔接：有人为人单体应用不能套用Devops进行运维，其实鹏哥并不认同这个观点。单体应用也可以使用Devops工具进行运维，但因为单体应用本身的特点，如臃肿等特点导致了并不能与Devops进行高效的衔接

当然并不是所有的单体应用都会有这些缺点，或者有时候，特定的场景下这些缺点也是他的优点，比如小团队，微需求等。

微服务的特点

为了应对这些单体应用的问题，架构师们提出了微服务的概念。微服务除了解决以上的痛点以外，还具备一下特点。 自责单一，自己维护：拆分出来的服务，只维护一个或一类功能，并进行独立部署，独立升级，只对自己负责。 逻辑清晰：因为只负责一个功能，所以逻辑划分非常清晰 部署简单：可以与Devops 进行深度融合，可以实现自动快速部署。 可扩展，高可用：根据不同的功能需要的负荷，可以动态的分配不同的资源进行部署，同时多节点，保证了系统的高可用。 * 支持技术异构：因为每个微服务都是独立部署，所以不同的微服务可以使用不同的技术栈。

Spring Cloud 与 Spring Cloud Alibaba

Spring Cloud

我们只要Spring Cloud 是通过Spring boot 封装了Spring以及一系列第三方的开源组件，为开发人员提供一个快速，稳定的，功能强大的组件库。通过Spring Cloud，只需要简单的配置就可以搭建一套简易版的微服务架构。Spring cloud 提供7个核心的微服务组件： 服务注册与发现 网关 负载均衡 熔断 配置中心 声明式服务调用 * 日志与链路分析

Spring Cloud Alibaba

Spring Cloud Alibaba 是阿里巴巴推出的基于第二代实现标准推出的一些成熟架构，阿里的架构是阿里在实践过程中总结和抽象出来的，已经在业界被广泛使用。Spring cloud alibaba 免费的组件包括一下几个组件：

• Nacos: 服务注册与发现，配置管理
• Sentinel：流量控制，熔断降级
• RocketMQ：开源，高性能的分布式消息队列
• Seata：分布式事务管理
• Dubbo:高性能Java RPC

为什么我要选择Spring Cloud Alibaba

Spring Cloud全家桶已经可以完全支持了微服务，为什么我还会选择Spring cloud Alibaba呢？ 鹏哥主要考虑的两个原因： Spring Cloud Alibaba 经过了阿里双十一的考验，更符合中国的国情。阿里的技术输出氛围很浓，有活跃的社区和完备的中文文档。 一些特殊原因很可能会导致某个框架禁止国内使用，当然Spring的风险不是很大，但不能保证Spring 引入的第三方都不存在这种风险，所以经量使用国产的优秀软件替换掉国外的软件(前提是不两个架构的表现半斤八两的时候优先选择国内的)。

进入正题

技术选型 先来一个系统技术选型的草图，里面暂时包括了第一阶段部分的组件，第二个版本可能会引入k8s等容器化技术以及云原生技术。

使用Spring Cloud alibaba 组件替换掉一部分Spring cloud的组件。

其他组件如Spring cloud sleuth 等继续使用Spring cloud中的组件，不做替换，等后期调研之后在决定使用什么组件。

版本选择

因为牵扯到3个组件，所以需要配好 Spring Cloud alibaba -> Spring Cloud -> Spring Boot 三者之间的版本。官方给出了一个推荐的版本列表;

因为在鹏哥写这篇文章的时候 Spring Cloud Hoxton.SR5 已经发布，所以鹏哥决定使用最新的版本尝试一把，如果不行再回退到推荐版本。

实战 我们基于Maven搭建这个微服务学习的例子。首先需要考虑我们项目的层级结构，鹏哥分析，首先需要有一个parent负责定义系统的JAR 版本，以及引入公共的组件，剩下的服务分为业务微服务和管理微服务(如网关等)，所以我们需要在分别定义两个子的parent 来管理这两类服务各自的依赖，另外因为我们需要使用声明式服务间调用，我们选用dubbo 作为RPC调用框架，就需要给restful 提供接口，所以我们需要有个子parent负责这部分的插件管理。 上边就像是一个大楼的骨架，我们把骨架定义好，后边就是填充的问题了。项目目录截图：

根部parent POM 截图：

app-parent POM 截图：

项目地址：

pengge-cloud​github.com

下期预告

下一节，鹏哥带领大家启动一个Nacos server端，并将本地的服务注册上去，并简单介绍nacos的原理。同时结合这个事例顺带说一下nacos和 eureka 的比较。

写在最后

Github上关于微服务的脚手架已经烂大街，为什么鹏哥还要重复找轮子呢？鹏哥并没有重复造轮子，这个项目的初衷不是为了搭建一个脚手架，而是为了一步一步的学习微服务架构。另外鹏哥只能说参与其中才能品味其中的滋味，只有自己一步步的走到最后，才能感悟到山顶日出的美好，不然他依然只会停留在别人的朋友圈里。 虽然鹏哥从17年就开始实践微服务，但是对于微服务的学习也是刚刚起步，所以这部教程即是为了方便大家，同时也是为了整理和总结鹏哥这几年在这方面的积累。 因为鹏哥也是刚起步，所以这部教程并不会太难，只要你跟着鹏哥的步伐，相信很快就能搭建自己的微服务脚手架，同时你还会学会为什么要这样搭建这个脚手架。好了今天分享就到这里吧。