项目架构演进过程

1.为什么做着做着服务就要分离出去?

(1). 团队一般有两种:

. 很会找钱的老板,有认识的人脉,找到钱也不还.. 疯狗一样的团队.

(2). 现实是很残酷的:
往往在创业时,选择了复杂的架构,认为项目是可以走很多年的.做着做着越来越复杂,规模越来越庞大.考虑的比较乐观,而且过度设计架构了.在没有钱的时候,最好是功能迭代实现(功能的升级、功能的全面).

. 很多创业公司的网上线,一年没几个流量.. 上线后一直没有盈利,2年后转型.. 如果找不到金主,也许倒闭.

(3). MVC的痛点:

. 网站的所有功能,肯定有主营的功能模块.
   比如java开发的,商品访问量大,而修改代码,重新编译,就要将所有代码全部编译一次.. 多点服务的话,可能还会有一个存储配置来专门管理config.如etd.. 当服务器的ip经常变,会有一个服务注册服务器consul.

2. go、php、Java承担角色:

2.1 公司混合架构:

. PHP:RPC调用核心库、http api与前端交互等
②. java、go核心业务组:核心业务封装、RPC微服务体系建设
③. 运维组:. 产品组:. 前端组:vue/react、移动端

:. 核心的原因不是因为技术上不能实现(在一定的范围内),而是技术栈、第三方库的成熟度的不同.. 虽然grpc也可以同时发布http api,但是灵活度和可控度不如直接使用某一个语言来做.

2.2 混合语言:

(1). Go负责:

. grpc负责核心模块的核心业务逻辑开发(订单、用户等).
   如下订单下到php,具体业务处理是由php来调用grpc功能.. Go-Micro负责微服务体系的建设:
   a. 具体调用是直连api,还是通过微服的方式consul来进行服务注册与发现是由go-micro来负责的.
   b. rpc api

③. gin负责前端交互部分(订单、用户等):
   a. 负责http api,取交互数据.

(2). PHP部分(swoft 2.x):

. 负责大部分模块的数据获取API,调用go写的grpc服务.. 以http api为主,接入go微服务体系(sidecar):
   php来调用go写的相关体系,在这个体系再转向grpc对应的地址进行调用.

(3). 其他配合组件:
mysql、redis5、elasticsearch、consul、etcd等.

你可能感兴趣的:(架构)