微服务是开发可扩展云原生系统的强大工具，但为了避免严重的系统灾难，需要认真设计才能成功。微服务并不是解决所有架构问题的普适方案，过度的设计、不当的应用和错误的理解容易导致系统灾难。选择正确的应用方向对于成功开发微服务极其重要，而权衡利弊做出正确的设计决策同样重要。下面详细讨论设计微服务时需要考虑的一系列因素：

一、确定微服务的边界。

微服务设计最常见的一个问题就是服务的大小问题。设计微服务边界，最可行的办法就是通过一系列方案来模拟现有的业务场景，某些特定的业务可能会同时匹配多个要素条件，此时就需要架构师权衡利弊。

1，工具类函数，加密解密引擎或者通知引擎。

2，恰当的子域，比如半数请求是搜索的情况，可以考虑将搜索功能独立出来

3，事务一致性，比如预定酒店需要保持事务一致性，而搜索不需要，就可以考虑将其独立出来

4，团队分工，比如搜索服务需要用到推荐算法机器学习等专家系统，可以由独立的专家团队开发成一个独立的微服务

5，单一责任，理论上单一责任可以用到方法、类或者服务上。但在微服务的上下文中，单一责任不一定需要映射到某个服务上，更可行的办法是将单一责任理解为单一业务功能或者单一技术能力。比如酒店客户信息的读取和写入操作可以使用命令查询职责分离CQRS方式来实现两个微服务

6，创新和速度，满足业务功能和快速交付,如何最快实现并产生价值是微服务最为重要的

7，耦合和内聚，设计微服务时，应尽量避免服务间过多的频繁通信和循环同步依赖

8，把微服务视为产品，综合考量服务的目标群体、部署灵活性和可复用行

二、设计微服务的通信方式

1，同步和异步的方式如何取舍，从原则上看，异步才是最适合开发微服务系统的，但异步机制会让系统设计极其复杂。最好的做法是开始时先用同步请求响应的方式，之后在异步通信有需要时再进行重构，也可以使用响应式编程框架，来必满用户的异步请求系统复杂化

三、服务编排

1，在一个微服务内部组装或调用多个微服务接口的做法是可以考虑的，但要因此新建一个微服务可能会创建很多细粒度、非自治跟业务不对应的组合微服务。可以考虑将上游服务数据向外推送的方式，下游微服务通过监听缓存或者消息中间件来获取需要的数据。

四、每个虚拟机应该运行多少个微服务

1，最好先在一台虚拟机部署关联的多个微服务

五、规则引擎和工作流引擎

1，如果规则或者工作流比较简单，数量也不多，尽量服务内编写规则或工作流，反之应该使用独立的引擎

六、数据库

1，原则上每个微服务应该都使用独立的数据库，某些简单场景就几张表，可以只使用一个数据库。 比如客户主数据和客户详情

七、确定事务边界

1，尽量避免分布式事务

八、服务的版本化

1，对REST服务进行版本化有三种方式：URL包含版本号，Http请求头设置版本号和自定义头部版本号信息

九、跨域设计

1，一种做法是在REST接口添加@CrossOrign ，另外一种做法是用API网关作为客户端唯一信任的域名

十、日志存放

1，由于各个微服务有可能独立部署，其日志文件也分散在各处，最好是将日志汇总到一处进行存储并提供查询分析功能。ELK和Graylog都是可以考虑的解决方案