一、微服务架构的定义
微服务（MSA）是一种架构风格，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。它有如下几个特征：
- 小，且只干一件事情。
- 独立部署和生命周期管理。
- 异构性
- 轻量级通信，RPC或者Restful。
快速回顾一下Martin Folwer对微服务的定义
二、 广发银行大数据平台微服务的边界与拆分
因为讨论的问题涉及银行的行为规范，出于合规的需要，本文讨论架构与设计，不过多涉及具体业务。
三、背景：广发银行关于客户全景视图与外部数据整合的需求
在银行里边，原来的各种系统的数据库逐渐拆分和脱离其持久层，并重新组合。银行把这些数据存储单元归纳到大数据平台中，也就是说，大数据平台充当了其他系统的数据库（可以想象成公共的大水池），并且进一步的，要求其具有数据分析、数据挖掘等数仓和大数据的功能。最后以服务的形式提供接口给其他系统使用，其他系统也渐渐的不再存储核心的数据或只存储部分核心、临时数据。
在这种情况下，大数据平台要求有很好的扩展性、高可用性、壮健性。在选型对外提供数据的支撑方案中，微服务化是一个很好的选择，也势在必行。
从客户全景视图-外部数据整合这个需求可以更好的理解银行是怎么样看用户研究用户的。
目前银行要求整合用户的数据有 基础信息、学历、工商、车证、征信、企业注册信息、手机信息。银行希望看到一个全视角360度的用户。
所以需要接入的第三方数据接口就比较多了。有鹏元的学历、车证、工商3个接口、百荣评分的接口、芝麻信用的接口、人行征信的接口、风铃接口、电信联通移动的数据接口。以后还会有更多的接口接入。
此处不讨论具体的接口内容，也不涉及具体的数据字段。仅讨论怎么样把第三方的数据查询并存到大数据分析平台中。
四、 微服务的进程：已经完成基础架构。服务粒度较大。
痛点：微服务的进程还处在初级阶段。查询服务上一个大粒度的服务。当遇到其中一个数据接口需要升级，其他接口直接受到影响，需要做回归测试、同时有短时间的服务不可用。
现状：7月版的几个需求。（其实这里有敏捷 和持续集成的意思，一个个版本不断的追加）
- 需要接入广州智数的数据接口，能进行电信手机号码信息的查询和核验。例如查一下某个号码的状态，是在线使用、还是已经不用，在网的时长是0-6个月，还是1-2年或更长。
- 接入联通公司提供的数据接口，功能与智数相似。
- 接入风铃提供的企业变更信息数据接口。
5月版已经完成的服务中，需要对服务进行拆分：
- 独立和拆分出百融评分的数据接口。
- 独立和拆分出鹏元的数据接口，包括查询车证、工商、学籍。
五、 服务划分的思考。（多微才算微）
查阅了一些资料，其中有可取和需要斟酌的划分方法，例如
- 拆分的粒度越小越好，例如以单个资源的操作粒度为划分原则。
- 功能完整性、职责单一性。
- 粒度适中，团队可接受。
- 迭代演进，非一蹴而就。
- API的版本兼容性优先考虑。
- 以代码量作为衡量标准，例如500行以内。
然而这些原则本身也没有确切的数据标准。例如拆分的粒度越小越好这一点。联通提供的数据接口包含查询手机使用状态、查询手机在网时长、查询手机所有者是否还存在其他号码、对手机所有者的身份核验等。那么是否应该拆分成4个微服务呢？至少现阶段我们不想这么做。因为目前的数据请求量还不高到必须单独部署扩容，代码的开发还没有产生十分可怕的耦合，没有产生太多的回归测试。而且服务一下子暴增，会导致部署工作和运维成本提高。
基于这些考虑，我们需要一个循序渐进的过程。服务的拆分按需要进行，围绕业务功能进行垂直和水平拆分。
- 拆分过程首先产生中粒度的编排层服务和小粒度的原子层服务。
- 拆分尽量不产生强一致性事务。
- 在供应商接口层面，做到功能完整性、职责单一性。
- 粒度适中，团队可接受。如果一个服务需要超过3个人员合作完成的，建议拆分。
- 考虑未来可能会独立出来的功能，划分到不同的接口。为以后的拆分做铺垫。
- 单个服务的代码量控制不超过8000行。但不强制执行。
我们最后得到这样的一个规划：
六、 疑问、求助与展望
然而，以上只是考虑了怎么样拆分，那么何时拆分？没有数据标准，也很难定下标准。
我们期待着更多的有效可行的研究结果，尤其是在服务治理方面。如果能较好的采集KPI（包括服务调用时延、服务调用QPS、内存CPU使用率等）、服务调用链可视化、故障快速定界、Devopts等自动化技术的介入。这些将会对服务划分、何时拆分会有指导意义。