康威定律
系统设计(产品结构)等同组织形式，每个设计系统的组织，其产生的设计等同于组织之间的沟通结构（简单点说就是，系统的设计受限于设计系统的组织的人员架构形式。我们也经常说微服务不光是一个技术问题，更是一个研发组织问题）。
微服务拆分原则和方法
1. 单一职责、高内聚低耦合
2. 服务粒度适中
3. 考虑团队结构
4. 以业务模型切入
5. 演进式拆分
6. 避免环形依赖与双向依赖
微服务拆分时机
一：提交代码频繁出现大量冲突
二：小功能要积累到大版本才能上线，上线开总监级别大会
三：横向扩展流程复杂，主要业务和次要业务耦合
四：熔断降级全靠if-else
服务拆分的规范
一：服务拆分最多三层，两次调用
二：仅仅单向调用，严禁循环调用
三：将串行调用改为并行调用，或者异步化
四：接口应该实现幂等
五：接口数据定义严禁内嵌，透传
六：规范化工程名
微服务的七大原则
1、围绕业务概念建模
经验表明，围绕业务的限界上下文定义的接口，比围绕技术概念定义的接口更加稳定。针对系统如何工作这个领域进行建模，不仅可以帮助我们形成更稳定的接口，也能确保我们能够更好地反映业务流程的变化。使用限界上下文来定义可能的领域边界。
2、接受自动化文化
微服务引入了很多复杂性，其中的关键部分是，我们不得不管理大量的服务。解决这个问题的一个关键方法是，拥抱自动化文化。前期花费一定的成本，构建支持微服务的工具是很有意义的，比如：自动化测试，调用一个统一的命令行，以相同的方式把系统部署到各个环境；使用环境定义来帮助你明确不同环境间的差异，同时保持使用统一的方式进行部署；创建自定义镜像来加快部署，创建全自动化不可变服务器。
3、隐藏内部实现细节
为了使一个服务独立于其他服务，最大化独立演化的能力，隐藏实现细节至关重要。隐藏服务的数据库，以避免陷入数据库耦合；使用数据泵（data pump）或事件数据泵（event data pump）,将跨多个服务的数据整合到一起，以实现报表功能。
4、让一切都去中心化
为了最大化微服务能带来的自治性，我们需要持续寻找机会，给拥有服务的团队委派决策和控制权。
在这个旅程中，确保团队保持对服务的所有权是重要的一步，理想情况下，甚至可以让团队自己决定什么时候让那些更改上线。使用内部开源模式，确保人们可以更改其他团队拥有的服务，不过请注意，实现这种模式需要很多的工作量。
像企业服务总线或服务编配系统这样的方案，会导致业务逻辑的中心化和哑服务，应该避免使用它们。使用协同来代替编排或哑中间件，使用智能终端点（smart endpoint）确保相关的逻辑和数据，在服务限界内能保持服务的内聚性。
5、可独立部署
我们应当始终努力确保微服务可以独立部署。我们也应该同时提供新旧两个版本，允许消费者慢慢迁移到新版本。当使用基于RPC的集成时，避免使用像Java RMI提供的那种使用生成的桩代码，紧密绑定客户端/服务器的技术。
通过采用单服务单主机模式，可以减少部署一个服务引发的副作用，比如影响另一个完全不相干的服务。请考虑使用蓝/绿部署或金丝雀部署技术，区分部署和发布，降低发布出错的风险。使用消费者驱动的契约测试，在破坏性的更改发生前捕获它们。
请记住，你可以更改单个服务，然后把它部署到生产环境，无需联动地部署其他任何服务，这应该是常态，而不是例外。你的消费者应该自己决定何时更新，你需要适应他们。
6、隔离失败
微服务架构比单块架构更具弹性，前提是我们了解系统的故障模式，并做出相应的计划。
如果我们心中持有反脆弱的信条，预期在任何地方都会发生故障，这说明我们正走在正确的路上。请确保正确设置你的超时，了解何时及如何使用舱壁和断路器，来限制故障组件的连带影响。如果系统只有一部分行为不正常，要了解其对用户的影响。知道网络分区可能意味着什么，以及在特定情况下牺牲可用性或一致性是否是正确的决定。
7、高度可观察
我们不能依靠观察单一服务实例，或一台服务器的行为，来看系统是否运行正常。相反，我们需要从整体上看待正在发生的事情。通过注入合成事务到你的系统，模拟真实用户的行为，从而使用语义监控来查看系统是否运行正常。聚合你的日志和数据，这样当你遇到问题时，就可以深入的解析原因。而当需要重现令人讨厌的问题，或仅仅查看你的系统在生产环境是如何交互时，关联标识可以帮助你跟踪系统间的调用。
