该系列的两篇文章《.Net微服务实战之技术选型篇》和《.Net微服务实战之技术架构分层篇》都是以技术角度出发描述微服务架构的实施。
如果技术选型篇叙述的是工具，那么架构分层篇讲的就是技巧，而本篇要讨论的就是原则。一直以来我会给身边向我探讨问题的人灌输一种理念，没有什么技术银弹，因为我们做的是软件工程，提供的是问题相应的解决方案，不同类型问题的解决方案是存在着本质上的差异。
继续提供之前的源码：https://github.com/SkyChenSky/Sikiro
PS：该篇文章与.Net无法，其实主要是沿用前面两篇文章的命名，此外我认为DevOps不是简单的工具使用，应从软件工程角度进行出发。
什么才是优秀的架构设计？曾经有好几个同行问过我同一个问题：什么才是优秀的架构设计？我一直信奉着两句话和一个定律：
架构服务于业务，技术服务于架构
康威定律（简单理解成组织架构的设计等同于系统架构的设计）
架构设计其实就是一种方案的取舍，在有限的资源里(包括但不限人力、时间)能让团队顺利的实施技术，同时满足业务规模的需要，我认为可以称之为优秀的架构设计，简单来说两个字合适
架构核心要素
核心的主要5大：性能、可用性、伸缩性、扩展性、安全性。
而我们所讨论的微服务，选择了扩展性，牺牲了可用性、性能，扩展性的目的就是为了快速响应需求变化、降低系统耦合度、提高系统模块的复用度。而微服务的调用是通过跨进程的网络通信的，跟进程内方法调用比无疑是慢了一个单位；原本单服务99.99%高可用，假如现在三个服务就是99.99%*99.99%*99.99%=99.97%。
当然我们可以在基于微服务的通过引入其他技术提高可用性、伸缩性和安全，但是确保无疑是牺牲了性能，除了性能还会在团队开发效率与运维复杂度上会受到影响。由此可见，没有万能技术手段，而架构其实在取舍。
引入一种技术必定带新的技术问题这是个必然结果，刚提到团队开发效率与运维复杂度会受到影响，那是否有办法缓解甚至解决并提高呢？既然涉及到团队、流程这些关键字那么就应该向软件工程方向寻找方案，合适架构实施还需要合适的开发模式进行支撑的，而风靡全球的DevOps就是不二之选。
软件工程在行业盛传的一条公式：软件 = 软件工程 + 程序，可想而知软件工程的占据多么重要的比重。那么什么是软件工程？百度是这么解释的：
软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。
我自己重新总结了一个软件工程的通俗描述，通过多人协作、有目标、有步骤、有计划的并使用科学方法论指导开发与维护程序的这个过程。也可以用一条公式表达：软件工程 = 工具 + 流程 + 模式。
软件工程的出现目的是为了解决软件危机的。软件危机其实是当时落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一列的严重问题的现象。那么三次软件危机是什么呢？我整理了个表格（详细可以自行百度阅读）
名称 时间 原因 解决方案第一次软件危机
20世纪60年代—70年代
使用机器语言或者汇编语言在特定的机器上进行软件的设计与编写，引出的“抽象性”和“可移植性”的问题 高级的编程语言+瀑布开发模式第二次软件危机