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等.
