１．高内聚低耦合原则：
- 确保每个模块只完成系统要求的独立子功能；
- 模块与模块间的联系最少且接口简单；
２．降低模块间耦合度：
- 越底层的模块，应该越稳定，越抽象，越具有高复用度；
- 减少依赖，避免模块依赖不稳定的模块；
- 提升模块的复用度，自完备性有时候要优于代码复用；
- 每个模块只做好一件事情，减少Common的比例；
３．依赖倒置：
- 高层模块不应该依赖低层模块，两者都应该依赖其抽象；
- 抽象不应该依赖细节，细节应该依赖抽象；
- 采用适配器模式适配各种云平台，数据库等，而不强依赖某种云平台和数据库;
设计模式６大原则（SOLID）
1.单一原则（Single Responsibility Principle）：
- 一个类或者一个方法只负责一项职责，尽量做到类的只有一个行为原因引起变化；
- 业务对象（BO business object）、业务逻辑（BL business logic）拆分；
2.里氏替换原则（LSP liskov substitution principle）：
- 子类可以扩展父类的功能，但不能改变原有父类的功能；
- 实际项目中，每个子类对应不同的业务含义，使父类作为参数，传递不同的子类完成不同的业务逻辑；
3.依赖倒置原则（dependence inversion principle）：
- 面向接口编程，抽象就是接口或者抽象类，细节就是实现类；
- 上层模块不应该依赖下层模块，两者应依赖其抽象；
- 抽象不应该依赖细节，细节应该依赖抽象；
- 通俗点就是说变量或者传参数，尽量使用抽象类，或者接口；
4.接口隔离（interface segregation principle）：
- 建立单一接口（扩展为类也是一种接口，一切皆接口）；
- 客户端不应该依赖它不需要的接口；
- 类之间依赖关系应该建立在最小的接口上；
- 复杂的接口，根据业务拆分成多个简单接口；
5.迪米特原则（law of demeter LOD）：
- 最少知道原则，尽量降低类与类之间的耦合；
- 一个对象应该对其他对象有最少的了解；
6.开闭原则（open closed principle）：
- 用抽象构建架构，用实现扩展原则；（总纲）
任何事都是过犹不及，设计模式的六个设计原则也是一样，制定这六个原则的目的并不是要我们刻板的遵守他们，而需要根据实际情况灵活运用。对他们的遵守程度只要在一个合理的范围内，就算是良好的设计。
１．高内聚低耦合
- 单一职责：每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情；
- 轻量级的通信方式：同步RESTful（GET/PUT/POST...），异步（消息队列/发布订阅）；
- 不推荐在服务与服务之间共享数据库；
２．高度自治
- 独立部署运行，部署，发布;
- 进程隔离:独立开发和演进,独立的代码库，流水线；
- 独立的团队和自治:团队对服务的整个生命周期负责，工作在独立的上下文中， 谁开发，谁维护。
３．以业务为中心
- 每个服务代表了特定的业务逻辑
- 有明显的边界上下文
- 能快速的响应业务的变化
- 隔离实现细节，让业务领域可以被重用
４．弹性设计
- 设计可容错的系统,拥抱失败,为已知的错误而设计:错误如依赖的服务挂掉,网络连接问题;
- 设计具有自我保护能力的系统:服务隔离,服务降级,限制使用资源,防止级联错误;
５．日志与监控
当产品环境出错时，需要快速的定位问题，检测可能发生的意外和故障。而日志与监控是快速定位和预防的不二选择，在微服务架构中至关重要。
６．自动化
当服务规模化后需要更多自动化和标准化的手段来提升效能和降低成本。
- 自动化测试必不可少，因为对比单块系统，确保我们大量的服务正常工作是一个更复杂的过程。
- 调用一个统一的命令行，以相同的方式把系统部署到各个环境。
- 考虑使用环境定义来帮助你明确不同环境间的差异，但同时保持使用统一的方式进行部署的能力。
- 考虑创建自定义镜像来加快部署，并且拥抱全自动化创建不可变服务器的实践。
关注公众号 soft张三丰
