我的一个微服务项目，有兴趣可以一起做

服务化架构

我们知道，早期的项目，我们都是把前后端的代码放在同一个项目中，然后直接打包运行这个项目，这种项目我们称之为单体项目，比如早期的JSP项目，我就会把前端页面和后端代码放在一起，然后一起进行编写，然后使用tomcat去运行，这就是一个很典型的单体项目。
而单体项目，我们知道，他的好处就在于部署很方便，上线很快，毕竟所有代码都在你手上，你直接运行起来是很方便的。因此，单体项目是中小型企业的首选，因为它交付快，上线快，开发也快，这也是单体项目的好处。
当然，单体架构的缺点也很明显。
由于这个服务直接运行在单台服务器上，那么只要这台服务器出问题，服务就直接出了问题，没有高可用性这么一说。并且由于所有的请求都由单台机器承担，因此他的查询压力很大，因此查询的效率也比较受影响。
而单体项目的改进方式也就是我们所说的集群，也就是集群架构模式，它强调可用性。
我们部署的所有服务都以集群的方式进行部署，虽然增加了硬件成本，并且部署更加复杂，但是好处就是，由于每一台机器上都是全量数据，因此即使某一台机器奔溃了，还有其他的机器顶住，不会出现直接服务不可用的情况。

当然，虽然可用性提高了，但是很明显，项目的复杂程度也大大提高。
因为每一台机器上都是全量数据，那么意味着，如果需要修改某一台机器上的代码或者数据，就需要同时修改其他各个节点上的代码和数据，因此耦合性极大，开发复杂度大大提高。并且这就导致，项目的开发变为了以技术为核心，而非业务为核心，要求在技术上实现各类集群。
所以改进方法你也知道了，也就是把每一个业务，都拆分为一个又一个的小服务，然后由这些服务互相配合工作组成一个完整的业务。
因此，服务化架构也就出现了。
它是将一个业务进行拆分，它将不同的业务以独立的进程进行运行部署，服务化架构强调的就是将业务进行垂直拆分后，形成的多个的模块独立部署，独立维护，同时逻辑上，虽然还是分层的结构，不过他从逻辑上单独剥离出来了一个服务层，而这个服务层会有专门的组来负责。
服务化架构是以业务为核心，那么技术如何进行选型，就不确定了。

早期使用的是ESB企业服务总线。
设想一下，早期是没有面向服务架构的规范的，那么意味着各种服务可能会有不同的开发方式，比如有些暴露的接口是RestFul的，有些是webserver的，由于格式不统一，那么项目就会更加复杂，而随着项目服务的增加，项目的复杂程度越来越大，我们所谓的shishan也就出现了。
所以IBM就提出了ESB企业服务总线，其中最核心的就是格式转化，他能帮助我们为不同的业务进行转化，从而避免了上面所述的问题。ESB就提供了一个中心化的注册中心，因此ESB是非常重量级的，他很重要，因为毕竟各类服务需要进行互相转化就需要依赖ESB，而ESB成本超级高，没有好用的开源，并且它属于重量级唱片，部署规划异常笨重。
因此，SOA的问题就在于各个子系统之间没有采用统一的通信标准，导致系统通信与数据交互间变得异常复杂。

所以，为了解决SOA的问题，就出现了微服务架构模式。

微服务架构

微服务架构风格是一种将单个应用程序开发为一组小型服务的方法，每个小服务运行在自己的进程中，并且以轻量级机制(通常是HTTP REST API)通信。这些服务是围绕业务能力建立的，并且可以由完全自动化的部署机构独立部署。这些服务的集中管理只有最低限度，可以用不同的编程语言编写并使用不同的数据存储技术。

目前比较主流的微服务架构就是SpringCloud和SpringCloudAlibaba了
在上面我写出的项目就是使用SpringCloudAlibaba，有兴趣的可以联系我一起开发哦