eureka框架的房产销售平台
2房产销售平台是我们日常生活中经常会用到的信息平台之一，它可以为我们选购适合的房产，并把这个行为体现在系统和数据记录上，为我们的生活带来便捷。本课题设计就是围绕房产销售平台这一主题，运用Spring Eureka微服务框架和软件开发相关技术去集成开发的房产、用户、房产经纪人、用户评论等信息模块的运营系统，其主要功能是实现用户对房产基本信息的浏览、评价和房产经纪人维护房产信息等。本文主要介绍了开发该系统用到的相关技术和系统核心模块功能的设计与实现。
目录
引言
引言
随着互联网技术的快速发展，人们的生活中的方方面面也都融入了互联网的浪潮。外卖、网上支付、共享单车等大家在生活中经常使用的名词和互联网技术，为我们的生活带来了极大的便利和改变。房产信息是我们日常生活中关注较多的信息，一个房产销售平台是集成房产信息浏览、用户注册、房产推荐、房产打分评论等功能的互联网网站应用，是现实生活中比较常见的应用场景。
本文阐述了基于Eureka微服务开发框架和软件开发规范流程，集成redis、spring admin等分布式缓存和监控等技术，运用mysql数据库和zookeeper等中间件开发的房产销售平台系统。在本系统中，普通用户和房产经纪人可以实现注册和登录、也可以对首页中的房产信息进行浏览、评分、评论等行为，其中房产信息中有户型图、售价、所属经纪人等常见信息，并且整个系统也可以展示热门房产和最新创建的推荐房产，具有高内聚、高可用性等特点。
1 系统概述
1.1 为什么采用微服务
在过去的软件应用开发的过程中，项目都是将应用程序的所有功能都打包成一个独立的单元，最终以一个war包或者jar包存在，没有外部的任何依赖，里面包含对数据库的操作、对逻辑功能的实现、用户交互所需的所有静态资源。这种开发部署方式叫做单体服务部署，这对以前IDE功能不强大的开发过程很有帮助，因为单体应用只需要单一的单元测试就可以跑通必现的所有需要测试的场景。同时单体应用也是单独的jar包部署，不存在其他多余所属依赖，单独的jar打包完成之后就可以在服务器上进行访问。但是在如今IDE越来越强大的开发时代，单一的集成测试似乎可以拆分成很多的部分进行集成的单元测试，并且在互联网业务的快速发展下，更新迭代的 *好棒文|www.hbsrm.com +Q: *351916072*
功能堆积和代码冗余使得单体应用越来越臃肿，造成了项目的交付效率会变的很低，经常会出现一个人等待上一个人把专属的模块开发完成之后才能进行自己单独模块的开发。这样使得这个应用很难去维护，并且阻碍项目实施给技术人员带来的技术成长。所以微服务的概念就顺势而生。
互联网公司中的微服务，顾名思义是将互联网中的单体应用拆分为多个高内聚低耦合的小型服务，每个小服务运行在独立进程，有不同的团队同时进行开发和维护，服务间采用轻量级通讯机制，独立自动化部署，可以采用和不同的编程语言和数据存储方式。以一个传统电商平台的单体化拆分为微服务架构为例（图1），在一个大团队的开发维护下，单体电商架构可以按照业务区拆分成为子微服务中心，实现拆分的过程。
图1电商架构演进
那么使用微服务开发架构又有什么好处呢？首先微服务架构本身来源于互联网的思路，因此组件化对外发布的服务强调采用HTTP Rest API的方式进行。这个角度来说，组件超外部暴露的能力才需要发布微服务，而现在一般的系统都是通过对逻辑的分析实现来组成公共对外的API的，像前端等这些外部调用者不需要去关心内部到底怎么去实现这段逻辑的，更加具有高内聚的特点。其次，微服务开发框架增强了各个开发团队之间的配合，提高了整体项目的交付效率。因为项目被拆分为多个业务模块为主的微服务框架，所以可以安排不同的团队去进行开发，并且现在流行的前后端分离开发也多元化了项目开发过程中的团队配合方式。最后，微服务最大的优势在于其增加了项目的伸缩性。以上图中的简单电商单体到微服务架构的进化为例，单体架构整个团队维护开发一个大工程及一个单库，到了微服务架构，用户请求经过API GateWay网关被路由到下游服务，服务之间以轻量级通讯协议进行通讯，服务通过注册中心发现彼此，每个服务都可以有专门的开发团队，每个服务对应独立的数据缓存和存储方式，服务独立开发，独立部署和上线。这样的架构增加了项目中各个服务模块的拓展性及伸缩性，如果要更改一段逻辑实现方式，完全不需要重新独立打包，只需要对逻辑更改所在的模块中独立部署即可。
本文要开发的房产销售平台是一个在业务上可以拆分为用户、房屋、评论、推荐、等业务模块的系统，非常容易去界定划分元服务的边界，并且后端采用Spring boot应用框架，对接入Eurkea框架有很好的适应性，很容易的实现可插拔性的微服务框架的拆分。所以，该系统用微服务框架进行开发。
微服务带来的挑战
任何的技术都是双刃剑，微服务架构技术也是如此，在解耦了各个业务模块的同时，也给开发带来了一定的挑战。首先，各个业务模块在分布式环境中拆分到不同的机器或者虚拟主机上，则相互之间的通讯就要遵循HTTP协议。在网络传输协议中，应用层和连接层在不同的协议之间是要建立起双工的长连接，这就要求各个模块之间的通讯能够有分布式中间件去保证。目前比较主流的实现服务之间通讯的方式有RPC调用、Restful调用、异步调用三种。RPC远程调用技术基于TCP，常用的技术选型有thrift、grpc等分布式调用框架，其通过idL来生成Java代码，对业务实现有良好的封装性和解耦性，可以轻量级的实现服务之间的通讯；异步调用则需要借助在分布式系统中成熟的消息策略中间件，如RockectMQ、Kafka等。其次，在分布式环境下有多个服务模块的存在，使得一个服务模块被另一个服务模块发现和各个模块的注册变得复杂起来。所谓服务注册，就是在一个统一的注册中心将各个模块注册上去，并且可以自动地去发布和调用别的模块的接口，这就需要我们将我们的服务信息注册到一个分布式存储中，这些服务信息就叫做服务注册表，服务注册表可以作为信息的权威来源。其中包含有关可用服务的信息，以及服务网络位置比如ip、端口号这些信息。那借助什么组件进行实现呢，这就需要我们的Eureka开发框架，除此之外我们还可以借助etcd、consul、redis这些成熟的分布式中间件。最后，当系统由分布式微服务技术实现的时候，那么对多个服务模块的监控和治理肯定不会少，我们必须清晰地感知和可以追溯到一次请求的链路和路径，并且还要有整个环境下的链路监控。这里的监控主要体现在：每个服务和使用的组件都有提供健康检测机制，使得我们可以及时发现异常的节点，然后做出判断和调整，将所有的监控指标进行聚合输出便于观察的界面帮助我们直观解决问题；一个多方位的全局日志检索。比如在电商app我们发现无法进行下单操作，在微服务环境下，日志拆分在不同的服务器上，我们不知道错误日志是打在哪台机器上，如果挨个去检索日志效率是机器低下的，这就要求我们做到日志标准化，并且通过一些手段去聚合索引，提供一个错误日志的全局搜索；一个请求的链路追踪。在微服务架构场景中，一个客户端发起的请求要经过多个服务的调用最终聚合数据结构返回给客户端，但我们不知道这个请求经过哪些服务，调用哪个服务出现了问题，每个服务的输入输出是什么，这给我们定位问题带来了困扰，除此以外，如果一个请求耗时较长，我们不知道到底哪个服务耗时最长，好有针对性的性能优化。随着架构的演进，我们在架构设计规划时需要知道 服务之间的依赖关系，这又需要什么技术来实现呢？这就是我们要介绍的分布式追踪，分布式追踪借助关联id，在请求源头创建这个关联id，并且在服务间进行透传，最终将关联id等信息聚合到一起进行查询分析。
目录
引言
引言
随着互联网技术的快速发展，人们的生活中的方方面面也都融入了互联网的浪潮。外卖、网上支付、共享单车等大家在生活中经常使用的名词和互联网技术，为我们的生活带来了极大的便利和改变。房产信息是我们日常生活中关注较多的信息，一个房产销售平台是集成房产信息浏览、用户注册、房产推荐、房产打分评论等功能的互联网网站应用，是现实生活中比较常见的应用场景。
本文阐述了基于Eureka微服务开发框架和软件开发规范流程，集成redis、spring admin等分布式缓存和监控等技术，运用mysql数据库和zookeeper等中间件开发的房产销售平台系统。在本系统中，普通用户和房产经纪人可以实现注册和登录、也可以对首页中的房产信息进行浏览、评分、评论等行为，其中房产信息中有户型图、售价、所属经纪人等常见信息，并且整个系统也可以展示热门房产和最新创建的推荐房产，具有高内聚、高可用性等特点。
1 系统概述
1.1 为什么采用微服务
在过去的软件应用开发的过程中，项目都是将应用程序的所有功能都打包成一个独立的单元，最终以一个war包或者jar包存在，没有外部的任何依赖，里面包含对数据库的操作、对逻辑功能的实现、用户交互所需的所有静态资源。这种开发部署方式叫做单体服务部署，这对以前IDE功能不强大的开发过程很有帮助，因为单体应用只需要单一的单元测试就可以跑通必现的所有需要测试的场景。同时单体应用也是单独的jar包部署，不存在其他多余所属依赖，单独的jar打包完成之后就可以在服务器上进行访问。但是在如今IDE越来越强大的开发时代，单一的集成测试似乎可以拆分成很多的部分进行集成的单元测试，并且在互联网业务的快速发展下，更新迭代的 *好棒文|www.hbsrm.com +Q: *351916072*
功能堆积和代码冗余使得单体应用越来越臃肿，造成了项目的交付效率会变的很低，经常会出现一个人等待上一个人把专属的模块开发完成之后才能进行自己单独模块的开发。这样使得这个应用很难去维护，并且阻碍项目实施给技术人员带来的技术成长。所以微服务的概念就顺势而生。
互联网公司中的微服务，顾名思义是将互联网中的单体应用拆分为多个高内聚低耦合的小型服务，每个小服务运行在独立进程，有不同的团队同时进行开发和维护，服务间采用轻量级通讯机制，独立自动化部署，可以采用和不同的编程语言和数据存储方式。以一个传统电商平台的单体化拆分为微服务架构为例（图1），在一个大团队的开发维护下，单体电商架构可以按照业务区拆分成为子微服务中心，实现拆分的过程。
图1电商架构演进
那么使用微服务开发架构又有什么好处呢？首先微服务架构本身来源于互联网的思路，因此组件化对外发布的服务强调采用HTTP Rest API的方式进行。这个角度来说，组件超外部暴露的能力才需要发布微服务，而现在一般的系统都是通过对逻辑的分析实现来组成公共对外的API的，像前端等这些外部调用者不需要去关心内部到底怎么去实现这段逻辑的，更加具有高内聚的特点。其次，微服务开发框架增强了各个开发团队之间的配合，提高了整体项目的交付效率。因为项目被拆分为多个业务模块为主的微服务框架，所以可以安排不同的团队去进行开发，并且现在流行的前后端分离开发也多元化了项目开发过程中的团队配合方式。最后，微服务最大的优势在于其增加了项目的伸缩性。以上图中的简单电商单体到微服务架构的进化为例，单体架构整个团队维护开发一个大工程及一个单库，到了微服务架构，用户请求经过API GateWay网关被路由到下游服务，服务之间以轻量级通讯协议进行通讯，服务通过注册中心发现彼此，每个服务都可以有专门的开发团队，每个服务对应独立的数据缓存和存储方式，服务独立开发，独立部署和上线。这样的架构增加了项目中各个服务模块的拓展性及伸缩性，如果要更改一段逻辑实现方式，完全不需要重新独立打包，只需要对逻辑更改所在的模块中独立部署即可。
本文要开发的房产销售平台是一个在业务上可以拆分为用户、房屋、评论、推荐、等业务模块的系统，非常容易去界定划分元服务的边界，并且后端采用Spring boot应用框架，对接入Eurkea框架有很好的适应性，很容易的实现可插拔性的微服务框架的拆分。所以，该系统用微服务框架进行开发。
微服务带来的挑战
任何的技术都是双刃剑，微服务架构技术也是如此，在解耦了各个业务模块的同时，也给开发带来了一定的挑战。首先，各个业务模块在分布式环境中拆分到不同的机器或者虚拟主机上，则相互之间的通讯就要遵循HTTP协议。在网络传输协议中，应用层和连接层在不同的协议之间是要建立起双工的长连接，这就要求各个模块之间的通讯能够有分布式中间件去保证。目前比较主流的实现服务之间通讯的方式有RPC调用、Restful调用、异步调用三种。RPC远程调用技术基于TCP，常用的技术选型有thrift、grpc等分布式调用框架，其通过idL来生成Java代码，对业务实现有良好的封装性和解耦性，可以轻量级的实现服务之间的通讯；异步调用则需要借助在分布式系统中成熟的消息策略中间件，如RockectMQ、Kafka等。其次，在分布式环境下有多个服务模块的存在，使得一个服务模块被另一个服务模块发现和各个模块的注册变得复杂起来。所谓服务注册，就是在一个统一的注册中心将各个模块注册上去，并且可以自动地去发布和调用别的模块的接口，这就需要我们将我们的服务信息注册到一个分布式存储中，这些服务信息就叫做服务注册表，服务注册表可以作为信息的权威来源。其中包含有关可用服务的信息，以及服务网络位置比如ip、端口号这些信息。那借助什么组件进行实现呢，这就需要我们的Eureka开发框架，除此之外我们还可以借助etcd、consul、redis这些成熟的分布式中间件。最后，当系统由分布式微服务技术实现的时候，那么对多个服务模块的监控和治理肯定不会少，我们必须清晰地感知和可以追溯到一次请求的链路和路径，并且还要有整个环境下的链路监控。这里的监控主要体现在：每个服务和使用的组件都有提供健康检测机制，使得我们可以及时发现异常的节点，然后做出判断和调整，将所有的监控指标进行聚合输出便于观察的界面帮助我们直观解决问题；一个多方位的全局日志检索。比如在电商app我们发现无法进行下单操作，在微服务环境下，日志拆分在不同的服务器上，我们不知道错误日志是打在哪台机器上，如果挨个去检索日志效率是机器低下的，这就要求我们做到日志标准化，并且通过一些手段去聚合索引，提供一个错误日志的全局搜索；一个请求的链路追踪。在微服务架构场景中，一个客户端发起的请求要经过多个服务的调用最终聚合数据结构返回给客户端，但我们不知道这个请求经过哪些服务，调用哪个服务出现了问题，每个服务的输入输出是什么，这给我们定位问题带来了困扰，除此以外，如果一个请求耗时较长，我们不知道到底哪个服务耗时最长，好有针对性的性能优化。随着架构的演进，我们在架构设计规划时需要知道 服务之间的依赖关系，这又需要什么技术来实现呢？这就是我们要介绍的分布式追踪，分布式追踪借助关联id，在请求源头创建这个关联id，并且在服务间进行透传，最终将关联id等信息聚合到一起进行查询分析。
版权保护: 本文由 hbsrm.com编辑，转载请保留链接: www.hbsrm.com/jsj/jsjkxyjs/1641.html
