摘要
进入新公司-立感网络已经两个月了，业务和系统架构已经了解的非常清楚，趁着这几天比较闲，把架构给梳理一遍。一来整理下学到的东西，二来也给后人入手这套东西留下一份文档。
业务概述
立感网络是做物流保险行业的业务的。相当于卖保险的吧，也是给保险公司打工的。卖出一份保险公司的保险，公司会得到一份提成或者推广费之类的收益。同时我们也招收代理人，他们可以拿着产品去卖，当然这时我们也会收提成。
- 需要对接保险公司
- 将保险公司的产品虚拟化为商品，让用户可以购买
- 招收代理人，就要有分销分账的机制
根据以上的业务需求，新系统架构师采用的是当前比较热门的微服务架构，旧系统还是传统的SOA架构。新系统现阶段将业务划分为以下几个服务。
服务的划分
新系统采用的技术有：
框架: Spring Cloud、Spring、Spring data jpa、Spring boot、Spring Mvc、Ibatis、Spring auth2。
数据库: MySql
构建工具: Gradle
持续集成: Jenkins+Gitlab
部署工具: Docker+Runcher
服务网关: kong、nginx
前端技术: vue2.0+gulp+webpack->H5页面、angular+webpack->后台管理系统
代码结构图
- app
- 专门为app服务的项目，提供和核心业务无关联的接口，但是是APP必须使用的接口。
- common
- 作为所有项目的依赖，提供统一的工具、异常、分页、常量、模块间访问的VO等各模块公用的类。
- crm
- 用户管理模块，负责用户登录验证、权限控制
- message
- 短信、邮件模块，接入阿里云短信服务，邮件服务
- payment
- 支付模块，接入的是宝付的支付系统，因为宝付提供分账功能
- policy
- 投保模块，提供投保工能，对接各个保险公司。
- product
- 产品模块，将各个保险公司抽象为产品，提供产品查询设置功能
- route
- Spring Cloud Eureka的注册中心
- security
- 安全模块，采用Spring auth2,作为各模块的依赖，提供统一的权限验证，跨域设置。
- task
- 任务模块，对于非自动出单的保险产品，需要人工处理，这里提供一系列的处理流。
对系统服务划分的思考
以上服务的划分，都是我来之前架构师已经搭建好的，后来架构走了，这个系统的演变也就停止了。后来的许多开发者各自遵循自己的代码风格，导致代码难以维护，一些原本很好的设计，由于大家都不准守，也就成了摆设。在数据访问层各个开发者采用自己喜欢的crm框架，SQL语句散落于代码中间。出现错误时都难以调整。至于其他方面也是差异颇多。
服务的划分边界大体上是清晰的，架构师把握的也很好，如果由架构师不走，也许会演变的更好。对于服务的划分，我的理解是：以业务为导向，厘清业务之间的关系，划分出业务边界。同时抽象出各业务公用的业务，再次进行划分。最后将一些边缘业务整合在一起，作为补充。
老夫资质驽钝，天资所限。对于划分服务的思考也只总结出这些。随着时间的增长，自己阅历的增加，定能更好的把握好这些。
总结
业务，服务的划分大致上就是这些了，微服务架构是最近两年比较流行的，特别是Spring Cloud这一系列的，当然还有别的微服务框架，比如阿里的dubbo，新浪微博的Motan等等，架构和框架是两个概念，实现微服务架构的框架等待我们去挖掘。同时和微服务架构一起兴起的还有容器技术，比如他的代名词docker。
