微服务化一:架构

底层服务:

系统服务:oss、缓存、日志、消息队列、短信、邮件等
核心业务服务:会员、权限认证
普通业务服务:各个业务模块
第三方服务:第三方服务接口对接

服务约定:

1.内网rpc接口,提供文档,严格测试,必须提供单元测试,严格保证服务的质量
2.服务独立,减少依赖,保证每个服务可独立部署和扩展,服务之间依赖 普通业务服务>核心业务服务>系统服务
3.统一注册到服务中心,命名规范
4.服务监控、报警、日志
5.自动化部署、持续集成、版本管理
6.应该提供个client sdk方便调用各个接口

*由于业务规模和人员配置,服务商不再封装2次服务,避免增加系统的复杂度,尽量使服务扁平化
*底层服务php天生优势不足,go和java更适合,但是技术栈在这里。。。哎

业务系统:

1.核心业务系统:直接对接底层服务的 系统服务和核心业务服务的称之为核心业务系统
2.普通业务系统:除了核心业务的所有系统,包括没有对接底层服务的独立系统系统

业务层主要职责:

1.从服务中心调用服务接口,组合成业务系统,
2.不论是api和网页服务都在这层写,所以这层可能会有几种技术选型
3.如果底层服务有些是对外服务的也写在此层,创建业务类型应该为系统服务业务,比如会员的单点登录、订单的支付等等

前端:

前端分为2种,
1:独立的前端,通过ajax和api通讯,api接口无状态,前端打包后可独立部署,
2:传统前端,依赖服务器端渲染的

架构选型:

选型原则:

1.基于现有技术栈
2.轻量化,在复杂度和扩展性之间,目前以降低复杂度为优先

*服务灰度发布、降级、自动化部署等整个体系雏形能正常运行后才逐步做

1.底层服务

php7+swoole 开发业务,框架目前选用swoft
consul 作为后端接口服务注册和发现
kong 作为前端接口网关
yapi 接口文档
phpunit 测试工具
gitlab 版本管理+git-runner作为自动化构建工具
服务监控、报警、日志系统待选型,openFalcon待测试,感觉底层知识欠缺,不好掌握

2.业务系统

选型原则:
1.比较流行,使用人群多,设计优良
2.适合目前团队现状和发展
3.根据业务需要选型,主业务系统用自己开发的,虽然迭代慢,但不至于由于第三方框架升级导致系统问题,因为目前php框架基本都基于composer,如果随时升级到最新版本,带来的工作量和问题不可预估
4.普通非重要业务,可以尝试新的主流框架,虽然会带来开发的和维护问题,但是可以保证开发人员接触的技术比较前沿,
5.用第三方的框架一个原则,不修改他核心代码为前提,即使放弃此框架不用,也不要去改核心代码

3.前端选型

这个就更混乱了。。。暂时没有想好如何处理,前端变化太快,自己维护一套组件难道大,耗时间,用第三方的,新旧更替,版本升级太频繁。。

开发步骤:

硬件:

3台机器,
1台做底层: 数据库、队列、存储、日志等(有钱了可以多台机器单独部署)
1台做底层服务 170,
1台做业务系统 179

标签: 无

发表评论: