2.1核心思想
相比于建造建筑物，在软件中我们会面临大量的需求变更，使用的工具和技术也具有多样性。
我们创造的东西并不是在某个时间点之后就不再变化了，甚至发布到生产环境之后，软件还能继续演化。
因此，必须改变那种从一开始就要设计出完美程序的想法，相反的，更应该设计出一个合理的框架，在这个框架下可以慢慢演化出正确的系统，并且一旦我们学到了更多知识，应该可以很容易的应用到系统中。
我们不应该过多的关注每个区域内发生的事情，而应该多关注区域之间的事情。
担心服务之间的交互，胜于过多关注各个服务内部发生的事情。
2.2目标、原则和实践
基于要达到的目标去定义一些原则和实践，对做设计来说非常有好处，不会偏离初衷。
目标
目标的层次一般都很高，通常也不会涉及技术层面，一般在公司或者部门层面指定。这些目标可以是“提高研发效率”或者“提升代码质量”。这些都是你的组织前进的方向，所以需要确保技术层面的选择能够与之一致。
原则
为了和更大的目标保持一致，我们会制定一些具体的规则，并称之为原则，它不是一成不变的。
一般来讲，原则最好不要超过10个，或者能够写在一块白板上，不然大家会很难记住。而且原则越多，他们发生重叠的冲突得可能性就越大。
实践
通过相应的实践来保证原则能够得到实施，这些实践能指导我们如何完成任务。实践应该巩固原则。
2.3规约标准
在微服务可以完成上述目标的同时，我们还需要识别出各个服务需要遵守的通用规则。
当我们在考虑一个更大的全景图时，图中应是许多系统由很多很小的但是有自治生命周期的组件构成，而且这些组件之间有着紧密的关联。所以在优化单个服务自治性的同时，也要兼顾全局。
我们应该清楚的定义出一个好服务应有的属性：
Ø 监控：能够清晰地描绘出跨服务系统的健康状态，各个服务以同样的方式报告健康状态与监控数据；
Ø 接口：选用少数几种明确的接口技术有助于新消费者的集成，不仅仅是技术和协议，要细化到规范（描述URL使用动词还是名词，如何处理资源分页，如何处理不同版本的API）；
Ø 安全性：必须保证每个服务都可以应对下游服务的错误请求（使用断路器、使用自己的连接池，返回码也应该遵守一定的规则）；
2.4组织管理
在开发软件的过程中，除了应该多思考墨菲定律，也要思考康威定律。
就如何做事情达成共识是一个好主意。但是，确保人们按照这个共识来做事情就没那么容易了。某些标准或许会成为开发人员的负担。有效的两种方式是：
范例：编写文档是有用的，但是开发人员更喜欢可以查看和运行的代码；
服务代码模板：针对自己的架构裁剪出一个代码服务模板，不但可以提高开发速度，还可以保证服务质量；
创建服务代码模板不是某个中心化工具的则指，也不是架构团队的职责。应该通过合作的方式定义出这些实践，所以你的团队也需要负责更新这个模板（内部开源的方式能够很好地完成这项工作）。
作为技术领导人来说，更重要的事情是帮助你的队友成长，并保证他们可以积极地参与到愿景的实现和调整中来，当这些人得到足够的锻炼之后，就可以更他们更多的责任，从而帮助他们逐步达成自己的职业目标，同时通过分担职责也可以防止某一个人的负担过重。
伟大的软件来自于伟大的人。如果你只担心技术问题，那么恐怕你看到的问题远远不及一半。
2.5小结
主要总结了在设计系统时，尤其是使用微服务设计系统时的一些思想、做法、标准和管理，并无落实到具体技术上。
在微服务系统中，设计者需要做更多的决定，因此，能更好的平衡这些决定带来的利弊是非常关键的。
接下来会从技术的角度来看如何设计微服务。
