whp1473
2019-05-28 14:16:54 +08:00
具体情况具体分析，不看公司规模和业务来就是耍流氓。
首先要看公司目的是什么？
如果工作定性为外包公司，那就搭建脚手架、代码生成平台、测试发布和运维平台、定制常用的类库和吸纳开源类库，做到快速开发和代码复用。
如果是某个公司的技术部门，不以技术为主要盈利人数较少，那我觉得不要分布式和微服务，建议全部上云减少运维成本，用 nignx 做软负载均衡即可。
如果是技术型初创公司，建议是用手底下最常用的技术先快速实现业务，然后做的大一些时在用也就 java 体系、GO 体系来重写业务框架。
至于使用分布式体系，以 java 为例，我觉得一般公司可以考虑下面的步骤：
(1)所有服务采用统一的技术体系，推荐 Springboot
(2)搭建统一的脚手架，可以参考开源的一些，包括不限于分布式框架选型(Dubbo、SpringCloud)，分布式缓存选型(Redis)、日志处理和格式(采集建议 ELK)、消息中间件选型(Kafak、RokatMq)、分布式定时任务选型(ElasticJob)、统一的工具类库(cooms、guvua、fastjson 等)、Mybatis、代码生成器、Mybatis-plus、分页插件、统一异常定义和处理、统一的请求拦截器等。
(3)编码规范定义，可以参考阿里规范，但要考虑实用性，不可能每个人都强制遵守，那些是重要的，必须遵守，那些是可以适度放宽的。Maven、git 命名、打包、发布规范。
(4)建立自动化发布运维的框架比如 jenkins、ELK、钉钉邮件预警、网关(zuul 普罗米修斯)流量监控报警，以及 WIKI 和类似禅道之类的 BUG 管理平台
(5)这些算是通用的底子，然后要根据现有的业务进行拆分，比如微服务的话可以对业务拆分，比如用户平台、权限平台、商品平台、交易平台、风控平台等。微服务之上可以考虑增加业务聚合服务，直接对应部分前端。所有对外服务都应通过网关统一对外暴露，在网关层面考虑用普罗米修斯之类的对调用做监控。对于用户平台需要考虑统一的登录注册，可以考虑在网关层增加对调用的管理。交易平台可能跟风控相关，通过日志采集发往相关的处理系统再回写到相关表中，风控提供相关接口。比如商品可能需要检索系统，那可以考虑在基础之上增加 ElasticSearch 对商品信息进行检索。比如活动平台可以考虑增加规则引擎，高度自定义规则，将规则配置移交给运营人员，减少重复开发。根据公司业务拆分成不同的小平台和业务，再根据其特点选择技术。
(6)原则上有开源的系统，就学习并使用开源产品，这样减少开发时间，但随着业务发展开源产品不能满足时，可以根据自身特点开发自己的产品，比如业界的工作流可能不能满足公司的需求，公司可以自己开发一套基于 XX 上的改进版本。就类似与 Dubbo->Dubbox，甚至开源出来回馈社区
最后技术只是为业务服务的，任何公司都是依靠业务发展的，追求优秀的技术是正确，但要一定要考虑公司自身的情况和寻找合适的时间>_<