SpringCloud微服务架构在实战项目中的总结
SpringCloud作为分布式微服务产品的研发生态来说是优雅且完备的，尤其是SpringBoot在团队研发中学习成本低，且能高效工作，因此相对于dubbo来说，SpringCloud是更多技术团队的首选。
在刚刚完成的一个智能还款的项目中，就应用了这样的架构来实施业务平台搭建。这里我们抛开业务本身不谈，只从技术层面对架构整体说明一下。
整体架构
整体架构图如下：
图中，我们以从上到下的方式首先对架构进行一次梳理：
- C端，我们涉及了几乎所有的端，权重较高的则放在了h5端。
- 接收到C端请求，以
VIP(虚拟ip)的方式切入Nginx负载。 - 请求到达网关
ZUUL，进而路由到自有服务marvel-facade marvel-facade是通往我们自有服务池的唯一入口，所有请求feign接口路由到具体服务。- 自有服务和服务之间也是通过
feign接口调用。 - 引入lcn服务进行分布式事物管理。
- 引入
FastDFS进行分布式文件存储。 - 引入
FELK进行分布式日志监控。其中F为filebeat - SpringCloud核心生态中我们着重使用了
BusConfigEurekazippin
细节总结
不要将所有的服务直接外露
引入marvel-facade层就是将所有的请求汇聚于此，然后根据具体业务逻辑通过feign调用。
优点如下：
- 对外暴露接口固定，于具体业务服务无关。（尤其重要）
- swagger接口有大局观。
配置中心文件可自动刷新
引入Spring Cloud Bus，并将marvel-config服务承担起刷新配置的职责,由此可实现远端git配置文件仓库发生改变，所有相关服务均可进行对应的刷新。
配置关键信息加密
配置文件统一放在配置中心，配置中心文件明文存在不安全，容易泄露比如数据库用户名、密码等，如何实现git仓库配置文件为密文时，通过配置中心在Config-Server端进行解密。建议使用JCE加密。
网关ZUUL很重要
除了做网关需要做的工作意外，对于用户认证、鉴权以及api接口请求的安全（包括反篡改）都要在这里完成。
分布式事物
项目微服务化了之后，分布式事物的问题便一定要处理好。
TX-LCN 和 阿里GTS 可任选一种。
jvm优化
主要集中在不管是用docker和java -jar的方式，要注意配置启动参数的调优。
nginx优化
ningx.conf 需要注意配置相关的线程数、连接数以及请求文件的大小限制等。
核心服务业务逻辑编写，要注重业务逻辑建模（非常重要）
对于业务核心逻辑（产品的主功能），通常研发人员为这样做：在controler中定义接收请求，处理请求，或者直接甩给service进行处理，而service层无脑的进行复杂的函数调用，这种函数编程的方式充斥着整个逻辑模块，使后续逻辑的重构变的及其困难。
其实这样做会更加合理，也更加使业务逻辑层次化，便于code review和拥抱重构:
- 深入理解你要编写的业务逻辑，试着加入
面向对象的思维，虽然面向对象似乎是一个被说烂的概念，但它真的非常重要，你也真的似乎还未完全理解和吸收它。 - 将
controler和service尽量当成入口来对待。处理请求的逻辑甩给业务建模对象来处理。 - 业务建模对象中抽象出业务属性和业务方法，配合使用对应的设计模式思想，引入
自定义注解反射和动态加载的机制抽丝剥茧，便终能成。
这似乎不是一蹴而就的，也许你可以试着使用之前的函数编程的方式编写业务逻辑，当发现可以重构的时候，便大刀阔斧的往这个方向上靠近。
最后
一个完整的微服务项目，首先要对使用的生态技术有个整体的把控，其不是简单的堆砌，可扩展、高并发以及安全和监控都要从一开始就要做到游刃有余才行。