微服务 在 Boss 的应用

2017-02-16  本文已影响0人  小兵张咔咔

目的

标准指标

具体步骤和里程碑

步骤的分解

（must） 认证服务器需要提前

需要在 nginx 后进行 CAS 的验证， 并且验证的信息是会放在session 里面的？ 这个的话， 好像有点问题， 因为session 已经是放在 缓存进行保存了， 需要咨询 劲飞。已经咨询过劲飞了， 可能验证的模块是当做是公用的模块， 同时 Session 是做到无状态， 下次做灰度测试的时候就会比较方便。 但是需要同时考虑到微信， 手机登录等各种操作， 做到统一性。

（must） 前后端代码进行分离

需要做到前后端人员能够快速进行开发。另外一个问题： 如何做到前端都可以做到分到模块来进行限制呢？

（must） 负载均衡 session 需要外部处理

直接调整 nginx 配置， 直接共享Session

（must） 后端代码模块直接切割

重中之重， 先拿一个 Customer 的模块 （这个模块选的有点大， 但是在实践过程中， 不断的缩小模块的范围， 让服务的切割， 不大不小， 刚好满足服务的界限， 而且考虑到人员的维护性； 或者拿 Customer 评价 这个模块） 进行验证。 这个涉及到下面的几个方面

**短期目标： **

  1. 直接拆分模块， 把 Customer 的模块 代码都独立出来， 依赖于原系统
  2. 对于 Customer 的模块， 对外围引用的模块， 界限上下文 必须要清晰， 分清晰 CoreDomain 和 辅助类型的Domain， 辅助类型的Domain 没有独立的表， 仅仅是 利用接口 获取到 的 ValueObject
  3. 对于 其他引用到 Customer模块的， 引入 因为 customer Domain 引发的 辅助型的 Domain， 没有独立的表， 仅仅是一个 ValueObject， 其他模块不能 直接import Customer 模块的类
  4. 还是使用原来的获取接口（直接调用方法）
  5. 模块分出来后， 就进行自己的版本基线控制

短期目标 具体步骤目标[http://www.jianshu.com/p/6b4ddd8b3bfb]

**中期目标： **

  1. 接口使用到 RPC 的方式来做到， 获取到 的 ValueObject
  2. 分离公用的第三方的库， 让 Customer模块 依赖于公用的库
  3. 分割模块后， 读取数据 和 业务 之间的区别？
  4. 如果读取是多个表的数据的话， 应该是如何去处理
  5. 业务 和 门面模式控制的业务， 应该是如何去分开

最终目标：

  1. 直接拆分模块， 把 Customer 的模块 代码都独立出来， 只依赖于公用类库
  2. 对于 Customer 的模块， 对外围引用的模块， 界限上下文 必须要清晰， 引入辅助类型的Domain， 辅助类型的Domain会有自己存储结构。
  3. 对于 其他引用到 Customer模块的， 引入 因为 customer Domain 引发的 辅助型的 Domain
  4. 使用到 异步更新 和 订阅消息的方式来更新

（must） 各个模块实现弱耦合， 尽量使用异步的方式进行

  1. 正常的业务流程， 使用 队列的方式进行交互
  2. 辅助性Domain属性的更新， 使用到 订阅者方式进行更新
  3. CoreDomain的属性的更新， 如果是其他模块引起的， 都是需要订阅者方式进行更新

这需要等 前面的 代码模块的切割 才可以比较好的实现。

（must） 引入 界限上下文 的概念， 让每个模块都控制在一定的范围内

（must） 服务注册和发现

使用 SpringBoot 和 ZooKeeper 的方式来做到服务的注册和管理

（must） UnitTest 的引入

对单独的模块可以进行 UnitTest 的验证， 做到每个模块快速进行自动化测试

每个模块独立的数据存储模块

有可能不同的模块是 使用不同的数据库等。

规范到每个模块的负责人

人员只负责自己的模块， 看不到别人的模块， 就可以限制出错的范围， 每次修改都是有信心的。

（must） 开发时候 每个模块的管理 和 部署

后端代码模块直接切割 短期目标 后

依赖项目， 还是整一个 War 的进行部署

后端代码模块直接切割 长期目标 后

利用到 Spring 和 ZooKeeper， 分离的方式进行部署

优化每个模块， 引入 读写模型 的 分离

监控不同的模块

安全 - 对外的白名单 nginx

持续化集成和交付

使用DDD的概念对整个模块内部代码进行整理

上一篇 下一篇

猜你喜欢

热点阅读