微服务的设计原则
1、高内聚低耦合
- 紧密关联的事物应该放在一起，每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情（每次只有一个更改它的理由)。如下图：有四个服务a,b,c,d，但是每个服务职责不单一，a可能在做b的事情，b又在做c的事情，c又同时在做a的事情，通过重新调整，将相关的事物放在一起后，可以减少不必要的服务。
- 轻量级的通信方式
- 同步RESTful（GET/PUT/POST...），基于http，能让服务间的通信变得标准化并且无状态，关于RESTful API的成熟度，可参
Richardson为REST定义的成熟度模型 - 异步（消息队列/发布订阅）
- 避免在服务与服务之间共享数据库
2、高度自治
- 独立部署运行和扩展
- 每个服务能够独立被部署并运行在一个进程内
- 这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。
- 独立开发和演进
- 技术选型灵活，不受遗留系统技术栈的约束。
- 合适的业务问题可以选择合适的技术栈，可以独立的演进
- 服务与服务之间采取与语言无关的API进行集成
- 独立的团队和自治
- 团队对服务的整个生命周期负责，工作在独立的上下文中， 谁开发，谁维护。
3、以业务为中心
- 每个服务代表了特定的业务逻辑
- 有明显的边界上下文
- 围绕业务组织团队
- 能快速的响应业务的变化
- 隔离实现细节，让业务领域可以被重用
4、弹性设计
- 设计可容错的系统
- 拥抱失败，为已知的错误而设计
- 依赖的服务挂掉
- 网络连接问题
- 设计具有自我保护能力的系统
- 服务隔离
- 服务降级
- 限制使用资源
- 防止级联错误
Netfilix 提供了一个比较好的解决方案，具体的应对措施包括：网络超时/限制请求的次数/断路器模式/提供回滚等。
5、日志与监控
当产品环境出错时，需要快速的定位问题，检测可能发生的意外和故障。而日志与监控是快速定位和预防的不二选择，在微服务架构中更是至关重要。
- 高度可观察，我们需要对正在发生的事情有一个整体的视角。
- 聚合你的日志，聚合你的数据，从而当你遇到问题时，可以深入分析原因。
- 当需要重现令人讨厌的问题，或仅仅查看你的系统在生产环境如何交互时，
关联标识可以帮助你跟踪系统间的调用。
监控主要包括服务可用状态、请求流量、调用链、错误计数，结构化的日志、服务依赖关系可视化等内容，以便发现问题及时修复，实时调整系统负载，必要时进行服务降级，过载保护等等，从而让系统和环境提供高效高质量的服务。
比如商业解决方案splunk，sumologic，以及开源产品ELK他们都可以用于日志的收集，聚合，展现，并提供搜索功能，基于一定条件，触发邮件警告。
Spring boot admin也可以用于服务可用性的监控， hystrix除了提供熔断器机制外，它还收集了一些请求的基本信息（比如请求响应时间，访问计算，错误统计等），并提供现成的dashboard将信息可视化。
关于性能监控和调用链追踪，考虑使用dynatrace和zipkin/Sleuth
6、自动化
在微服务架构下，面临如下挑战：
- 分布式系统
- 多服务，多实例
- 手动测试，部署，发布太消耗时间
- 反馈周期太长
传统的手工运维方式必然要被淘汰，微服务的实施是有一定的先决条件：那就是自动化，当服务规模化后需要更多自动化和标准化的手段来提升效能和降低成本。
- 自动化测试必不可少，因为对比单块系统，确保我们大量的服务正常工作是一个更复杂的过程。
- 调用一个统一的命令行，以相同的方式把系统部署到各个环境。
- 考虑使用环境定义来帮助你明确不同环境间的差异，但同时保持使用统一的方式进行部署的能力。
- 考虑创建自定义镜像来加快部署，并且拥抱全自动化创建不可变服务器的实践。
自动化一切可以自动化的，降低部署和发布的难度, 比如： 在持续集成和持续交付中，自动化编译，测试，安全扫描，打包，集成测试，部署，随着服务越来越多，在发布过程中，需要进一步自动化蓝绿部署（做到老版本到新版本的平滑过渡）还可以使用pipeline as code的实践，用代码来描述你的流水线。关于部署有很多选择，可以使用虚拟机，容器docker，或者流行的无服务架构lambda（AWS Lambda 也有一些明显的局限。它并不适合被用来部署长期运行的服务，请求需要在 300 秒内完成，当然你可以通过hack的方式延迟时间)。
然后， 可以采用基础设施及代码的实践，比如亚马逊的cloudformation，还有terrform，通过代码来描述计算和网络等基础设施， 可以快速为一个全新的服务，构架它所需要的环境，保持各环境的一致性。
