Rei的博客

1. 微服务的原则围绕业务概念建模，经验表明，围绕业务的限界上下文定义的接口，比围绕技术概念定义的接口更稳定。 拥抱自动化文化，微服务包含太多复杂性的东西，比如我们不得不管理大量的服务。所以最好的方式是在前期花费一定的时间构建支持微服务的工具；还有自动化的测试，部署脚本等等，能够帮我们做大多数耗时间的事情。 隐藏内部实现细节，为了使一个服务独立于其他服务，最大化独自演化的能力。限界上下文建模在这方面可以提供帮助。服务还应该隐藏它们的数据库，以避免陷入数据耦合。在可能的情况下选择支持通用技术的API，

1. 故障无处不在从统计学上来说，规模化后故障会成为必然事件。所以我们在设计实现微服务系统时只需要尽可能把多的可能故障的因素考虑进去，就可以尽可能保证系统的可用性。2. 功能降级微服务系统是由多个服务协同在一起工作的，当某个服务宕机时，我们需要考虑系统的对外表现是怎样的，比如商城系统的购物车服务挂掉了，这时候我们是选择让用户可以继续浏览商品还是将商城主页设置为“系统维护中”呢？这需要结合业务上下文来做决策，通常一个服务挂掉后，我们不会将整个系统设置为不可用，而是适当的处理，部分功能仍然可用，

1. 身份验证与授权当谈到与系统交互的人和事时，身份验证和授权是核心概念。我们一般把要进行身份验证的人或物成为主体。对于单块系统来说，app本身会处理身份验证和授权。比如Django提供现成的用户管理功能。但是在分布式系统领域，我们希望用户仍然使用一套用户名密码来使用整个系统，也就是单点登录（Single Sign-On）。当主体尝试访问一个资源时，会被定向到一个身份提供者那里进行身份验证，这个主体必须提供用户名密码进行验证，一旦身份提供者确认主体可以通过验证，它会发消息给服务提供者，让后者决定

1. CI(持续集成)CI技术已经出现很多年了（出书年是2015），因为在微服务之间的映射、构建以及代码库版本管理等方面，不同的考虑会有不同的选择。CI能够保证新提交的代码与已有代码进行集成，从而让所有人保持同步。CI服务器会检测到代码并检出（check-out），然后花些时间来验证代码是否通过编译以及测试能否通过。CI的好处有很多。通过它，我们能够得到关于代码质量的某种程度的快速反馈。CI可以自动化生成二进制文件，并且使用的代码都会归纳到版本控制，所以CI可以很方便的完成更新、测试、回滚的高度

1. 识别出接缝处（限界上下文）单块系统不具备高内聚、低耦合的特点，所以分解的第一步需要很谨慎，首先就是要识别出接缝的位置，我们可以从接缝处抽取相对独立的一部分代码，修改这部分不会影响系统的其他部分，并且能够清理代码库以及成为服务的边界。很多编程语言都有命名空间的概念，帮助我们把相似代码组织到一起，如Python/JAVA/Go等都有package概念，当我们识别出限界上下文后就可以通过pkg将它们分开维护。2. 更有效率的分解如果要分解一个较大的单块系统，那需要对分解的代码做一些优先级划分

1. 好的微服务架构都具备什么特点应该具备两个核心特点，松耦合、高内聚。这两个核心特点应该是一种仅次于SOA概念层级的概念，不遵循（或不具备）这两个核心特点的话，讨论更多的细节都没有什么意义了，更不可能建设出一个优秀的微服务架构实践了。2. 松耦合如果做到了服务之间的松耦合，那么修改A服务就不需要修改B服务。使用微服务最重要的一点是，能够独立修改及部署单个服务而不需要修改系统的其他部分，这是非常重要的。一个松耦合的服务，应该尽可能地少知道与之协作的那些服务的信息，一个小的实践就是接口需要的参

1. 监控能够清晰的描绘出跨服务系统的健康状态非常重要，这必须在系统级别而非单个服务级别进行考虑。往往在需要诊断一个跨服务的问题或者想要了解更大的趋势时，你才需要知道每个服务的健康状态。简单起见，作者建议确保所有服务都是用相同的方式报告健康状态及其它监控相关的指标数据。2. 统一服务接口技术选择少数几种（甚至一种）明确的接口技术有助于新消费者的集成。3. 架构安全性一个运行异常的服务可能毁了整个系统，我们需要保证每个服务能够应对上游服务的错误响应。这通常需要引入一个断路器，而断路

1. 什么是微服务？是一些协同工作的小而自治的服务。2. 为什么会有微服务架构？传统的单体应用架构在开发大型项目时的缺点是突出且严重的：一个庞大的代码库，以至于时间久了想要知道该在什么地方修改都很困难 相似的功能代码随处可见，修复bug难上加难 严重的耦合性问题，代码牵一发而动全身，代码结构的修改（重构）成本极高 一个小的修改就得对整个应用重新部署上线，上线成本高使得上线周期长，难以同步快速变化的需求 心智负担3. 微服务的特点- 优点根据业务特点拆分多个服务进行部署，服务

本文将总结关于如何构建一个IM架构相关的知识。1. 将【接入服务】与【业务处理服务】独立拆分理由有二，一是任务分工不同，接入服务负责建立并保持与客户端的连接、消息的编解码、协议解析等一些IM前台服务（也可以叫做网关），是最接近用户的服务，而且要在流量高峰期进行快速的性能扩展；而业务处理服务则是整个IM架构的核心，经常会随着业务需求不断变化而进行频繁的版本迭代，服务升级就意味着需要重启，...