2、微服务思想

2.1核心思想

相比于建造建筑物，在软件中咱们会面临大量的需求变动，使用的工具和技术也具备多样性。

咱们创造的东西并非在某个时间点以后就再也不变化了，甚至发布到生产环境以后，软件还能继续演化。

所以，必须改变那种从一开始就要设计出完美程序的想法，相反的，更应该设计出一个合理的框架，在这个框架下能够慢慢演化出正确的系统，而且一旦咱们学到了更多知识，应该能够很容易的应用到系统中。

咱们不该该过多的关注每一个区域内发生的事情，而应该多关注区域之间的事情。

担忧服务之间的交互，胜于过多关注各个服务内部发生的事情。

2.2目标、原则和实践

基于要达到的目标去定义一些原则和实践，对作设计来讲很是有好处，不会偏离初衷。

目标

目标的层次通常都很高，一般也不会涉及技术层面，通常在公司或者部门层面指定。这些目标能够是“提升研发效率”或者“提高代码质量”。这些都是你的组织前进的方向，因此须要确保技术层面的选择可以与之一致。

原则

为了和更大的目标保持一致，咱们会制定一些具体的规则，并称之为原则，它不是一成不变的。

通常来说，原则最好不要超过10个，或者可以写在一块白板上，否则你们会很难记住。并且原则越多，他们发生重叠的冲突得可能性就越大。

实践

经过相应的实践来保证原则可以获得实施，这些实践能指导咱们如何完成任务。实践应该巩固原则。

2.3规约标准

在微服务能够完成上述目标的同时，咱们还须要识别出各个服务须要遵照的通用规则。

当咱们在考虑一个更大的全景图时，图中应是许多系统由不少很小的可是有自治生命周期的组件构成，并且这些组件之间有着紧密的关联。因此在优化单个服务自治性的同时，也要兼顾全局。

咱们应该清楚的定义出一个好服务应有的属性：

Ø   监控：可以清晰地描绘出跨服务系统的健康状态，各个服务以一样的方式报告健康状态与监控数据；

Ø   接口：选用少数几种明确的接口技术有助于新消费者的集成，不只仅是技术和协议，要细化到规范（描述URL使用动词仍是名词，如何处理资源分页，如何处理不一样版本的API）；

Ø   安全性：必须保证每一个服务均可以应对下游服务的错误请求（使用断路器、使用本身的链接池，返回码也应该遵照必定的规则）；

2.4组织管理

在开发软件的过程当中，除了应该多思考墨菲定律，也要思考康威定律。

就如何作事情达成共识是一个好主意。可是，确保人们按照这个共识来作事情就没那么容易了。某些标准或许会成为开发人员的负担。有效的两种方式是：

范例：编写文档是有用的，可是开发人员更喜欢能够查看和运行的代码；

服务代码模板：针对本身的架构裁剪出一个代码服务模板，不但能够提升开发速度，还能够保证服务质量；

建立服务代码模板不是某个中心化工具的则指，也不是架构团队的职责。应该经过合做的方式定义出这些实践，因此你的团队也须要负责更新这个模板（内部开源的方式可以很好地完成这项工做）。

做为技术领导人来讲，更重要的事情是帮助你的队友成长，并保证他们能够积极地参与到愿景的实现和调整中来，当这些人获得足够的锻炼以后，就能够更他们更多的责任，从而帮助他们逐步达成本身的职业目标，同时经过分担职责也能够防止某一我的的负担太重。

伟大的软件来自于伟大的人。若是你只担忧技术问题，那么恐怕你看到的问题远远不及一半。

2.5小结

主要总结了在设计系统时，尤为是使用微服务设计系统时的一些思想、作法、标准和管理，并没有落实到具体技术上。

在微服务系统中，设计者须要作更多的决定，所以，能更好的平衡这些决定带来的利弊是很是关键的。

接下来会从技术的角度来看如何设计微服务。