微服务设计需要考虑的内容

参考书籍《微服务设计》《微服务架构与实践》

微服务的优点：

1.技术异构：不同的服务可以尝试使用不同的技术（比如高并发的服务是不是可以尝试使用nodejs 这种适合高并发的技术？针对高并发的数据操作，可以考虑使用内存数据库类似的技术，而对于一般不怎么用或者性能要求不高的服务则用常规的技术和数据库即可）

2.弹性：一个服务故障不会导致级联故障（通过将不同的实例运行在不同的机器上来降低功能完全不可用的概率）

3.扩展：单块服务即使只有很小的一部分有性能问题，也需要对整个服务进行扩展。小的服务可以只对需要的服务进行扩展。比如开户做活动时就只需要对开户的服务进行横向的部署，而购买产品的服务就不需要做任何的动作。

4.简化部署：单块应用即使只修改一行代码也需要部署整个应用，影响大风险高。小服务可以快速部署，快速回滚。

5.可组合性：更方便的重用已有功能（这个有利于减轻新应用开发工作量，比如手机团队也卖基金，如果我们对于基金的信息有个服务，那么他们就不需要再次做各种接口，直接调用我们的服务就可以了）

6.小团队的高效性：目前我们已经是小团队作业了，已经具有了小团队高效性的特点了

7.对可替代性的优化：一个小服务，如果想优化或者替代，很方便。如果是单个大应用，一般没人敢动（鬼知道有多少影响）。 

完成微服务设计或者改造需要做什么：

1.增加测试代码以及引入持续集成平台（如Jenkins）

     即使不使用微服务架构，针对关键功能以及工具类引入单元测试也能够有效的避免修改引入新的bug，可以减少人工测试的工作量，增加开发效率

    （至于集成测试，针对我们目前的实际情况—和各种我们无法控制的平台进行数据的交互，不建议使用过于复杂的自动的集成测试，用人工进行集成测试可能更适合我们）

     目前的问题是我们使用的是私有的开发框架，是否方便以及有效的引入开源的单元测试框架。

     接口开发要有明确的接口规范定义。

     需要把持续部署映射到各个服务的测试环境（生产环境的部署怎么处理？）

     怎样定制化镜像（和docker 集成）

     能否保持测试环境和生产环境的一致性（比如测试环境也有负载均衡）

2.log日志平台

   需要对日志进行规范，需要考虑如果一个请求路由到不同的服务上或者相同的服务不同的实例上之后怎样能够快速的检索到用户的调用链。同时如果出现问题，怎样能够快速的定位问题。

3.服务监控平台

   机器的运行情况，服务的运行情况，接口的访问次数以及成功率，服务之间的调用关系，服务的部署架构图等

   预警/报警参数是否可配置？预警/报警方式都是什么？

4.架构安全性

   (1) 如果一个服务出现异常，为了不影响其他服务，应该怎么处理(比如如果所有的服务使用的是同一个链接池，那么一个服务响应较慢，导致链接被占完，那么会影响整个应用的不可用)

        每个微服务设计时都需要考虑我这个服务宕掉会发生什么？会对其他服务或者整个应用造成什么样的影响。

   (2) 对于上游终端访问的权限控制管理 以及 服务之间的访问控制管理怎么做

5.服务的划分

    松耦合：能够独立修改以及部署单个服务而不需要修改系统的其他部分

    高内聚：相关行为聚在一起，改变

    从功能考虑，而不是从数据考虑。

   《领域驱动设计》

6. 服务之间的集成

    哪些服务适合请求/响应 的模式，哪些服务适合基于事件的协作方式

    如果使用事件的协同处理，怎样进行流程的监控？需要如果一个一个业务流程处理失败，其他业务流程怎样处理？如果有事务的要求，事务怎样处理？

7.服务间怎样进行静态数据的共享

  (1) 关系型数据库？

  (2) 数据copy 多份存储到多个服务中？

  (3) 统一的内存数据库进行共享？

8.整理报表需求

   报表很可能要跨不同的服务进行数据的获取。如果通过http 接口进行数据的获取就会给系统带来额外的不必要的压力。

   需要从数据库层面进行考虑，把不同服务的数据推送到中央报表数据库（只读数据库）

   当然这个需要根据报表的时效性考虑不同的方法和技术。

9.服务间的身份验证和授权

   需要怎么做呢？

   如果是限定了ip，那么对于服务的动态横向扩展有限制。

   如果每个服务/API都要做用户验证，那么对于服务的性能又有一定的影响

   提供给第三方或者一些很重要的API如果需要单独的API密钥，怎样处理？ 

   通过网段进行隔离？ 

如果需要选用第三方微服务平台需要考察的内容：

1.部署（注册，管理）：自动发现还是需要手动注册？

2.监控：挂载的服务，性能，日志（使用什么工具进行日志的聚合以及问题的定位），应用的性能

3.安全：身份验证和授权

4.流量：负载均衡

5.高可用：高可用部署方案

6.吞吐量：最大并发量，可以挂载的服务量

7.针对异步请求（事件）的处理

8.针对协同工作，怎样监控状态？

9.对于事务的解决方案：分布式事务

10.对于报表需求的处理（对于数据集中需求的处理）

11.身份认证的实现方式？是每个服务都进行单独的验证还是？是否有单点登录？

12.服务之间的身份认证怎么做？

13.服务间访问http链接池以及超时控制？断路器？每个下游服务使用不同的链接池，这样即使一个链接池用尽也不会影响其他服务的链接

14.分布式协调系统（服务的注册和发现）是自己的算法还是开源的工具？

    这个比较重点，如果是自己的算法，那么可能会存在过多的隐藏的bug，而开源的工具大家都用，更有利。

15. 是否具有对服务进行健康检查的能力

16.支持什么样的分布式事务（这个取决于业务需要什么样的事务）

17.综合监控：机器状态，服务状态，接口状态以及调用次数，接口响应时间，预警/报警参数设置以及预警/报警 方式

18.服务间的依赖管理