PHP微服务RPC通信（1）传统模式开发模式和微服务的区别

背景

近一年，因为公司业务极度增长，发展成PC端、移动端、小程序端、APP端拥有多端的项目。

现在前后端分离大行其道，于是也采用了前后端分离的模式，前端基于Vue+Element，后端Web基于ThinkPHP。

因为公司最开始经费的问题，一直是单服务器，前端和后端都在一台服务器不同端口，这样的一个项目。

项目臃肿，新员工上手不易，十分头疼，就想到了如何拆分项目，早有听闻大厂都已使用微服务架构。决定仔细研究一番，希望同各路大佬一起探讨。下面是正题。

 

 

传统模式开发模式

现阶段我公司项目架构是这样的：

优点：

1、开发简单，集中式管理，

2、基本不会重复开发，

3、功能都在本地，没有分布式的管理和调用消耗，

4、部署容易，如php写的项目，只要一个文件夹复制到支持php的环境就可了，java只需要一个jar包，

5、测试容易，我们整体项目只要改了一个地方马上就可以测试得出结果等;

缺点：（在公司日常开发全部遇到，而且非常头疼）

1、效率低：开发都在同一个项目改代码，相互等待，冲突不断，

2、维护难：代码功功能耦合在一起，新人不知道何从下手，

3、不灵活：构建时间长，任何小修改都要重构整个项目，耗时，

4、稳定性差：一个微小的问题，都可能导致整个应用挂掉，

5、扩展性不够：无法满足高并发下的业务需求，

6、部署的问题：对于php来说这点还好，但是对于java的项目来说，我们需要重新打包整个项目的代码维护，由于所有的代码都写在一个项目里面，要想要修改某一个功能点那么需要对项目的否则代码耦合严 重，导致维护难，特别对于新入职的员工来说这将是最容易出现问题的地方，

7、开发效率低：随着项目需求的不断改变和新的功能新增，老旧的代码又不敢随便删除，导致整个项目变得笨重，这将会增加你阅读代码的时间，

8、扩展性：在高并发的情况下，我们往往不是整个项目的每一个功能都处于高流量高请求的情况下的，很多时候都是某一 个功能模块使用的人数比较多，在单体结构下我们没有办法针对单个功能实现分布式扩展，必须整个项目一起署，

9、从公司利益的角度出发，保密性比较差，只要是新员工就可以得到全部源代码；

微服务架构介绍 

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决的解耦。

你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。

微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。 本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

 

如果按照上述的要求和我的项目结合拆分的话，预计应该是这样的

优点：

有效的拆分应用，实现敏捷开发和部署 分工不同，以前我们可能是一个一个模块，现在可能是一人一个系统。

架构不同，服务的拆分是一个技术含量很高的问题，拆分是否合理对以后发展影响巨大。

部署方式不同，如果还像以前一样部署估计累死了，自动化运维不可不上。

容灾不同，好的微服务可以隔离故障避免服务整体down掉，坏的微服务设计仍然可以因为一个子服务出现问题导致连应。

扩展不同，微服务更容易按需求进行横向和纵向扩展。微服务是一种架构设计，并不是说什么框架或者代替什么。 微服务做的事情是按照项目颗粒度进行服务的拆分，把模块单独拿出来做成每一个单独的小项目。微服务的主要特点有： 每一个功能模块是一个小项目、独立运行在不同进程或者机器上、不同功能可以又不同的人员开发独立开发不松耦合、 独立部署不需要依赖整体项目就可以启动单个服务、分布式管理。每一个服务只要做好自己的事情就好了。 在设计微服务的时候还需要考虑到数据库的问题，是所有微服务使用共同一个数据库还是每一个服务单个数据库。

缺点：

 如果想选择使用微服务需要重点考虑以下几方面的因素： 因为微服务的复杂度，对技术要求高，所以要考虑团队是否已经具备相关技术基础。 公司业务是否适合进行微服务化改造，并不是所有的平台都适合进行微服务化改造，传统行业有很多复杂垂直的业务构。 微服务生态的技术有很多，并不是每一种技术方案都需要用上，适合自己的才是最好的。

 

以上是我总结出来的第一章，后续还有。放上一张网上通用的架构图

对于broker的理解，后续再说。