最近在读Sam Newman的《Building Microservices》,让我对微服务又有了新的认识，当然也包括对SOA的进一步理解，需要整理一下新知，以让这些知识融入自己的知识体系，为我所用。
微服务是2014年由大神Martin Fowler提出来的一种架构设计理念，同时在Spring Cloud以及Dubbo技术的推动下，微服务迅速红遍大江南北。
而我对于微服务的理解就是将过去的单体应用拆分成彼此之间能够通过服务接口进行通信的尽可能小的组件服务，再加上我用上了Spring Cloud，那么我的系统就是微服务架构了。
其实看起来还是挺像那么回事儿的，但是现在看来还是“Too Young! Too Simple! Too Naive!"
什么是微服务
微服务是一种基于“高内聚、低耦合“设计原则的架构模式，是由一组可独立释放的业务领域服务组成的系统架构，各个服务之间通过网络进行通信，共同对外提供服务。
微服务中每个服务都可以看做是一个黑盒，其内部的实现细节、技术架构、变化对外界都是无感的。这样的设计符合信息隐藏的理念，即尽可能的将更多的信息隐藏在组件内部，同时通过对外接口也尽可能暴露更好的信息。这样能够保证边界清晰，让我们清楚知道哪些是对变化开放的，哪些是对变化封闭的。
微服务的关键就在于构建一个清晰、稳定的服务边界，这表示服务内部发生变化时不会对外界系统造成影响，进而做到低耦合、高内聚。
微服务与SOA的关系
SOA是一种针对服务协同的设计方法，旨在解决大型单体应用的软件复用问题，它的目的是使维护或重写软件变得更容易。应用SOA的方法，理论上讲只要服务语义不发生太大的变化，就可以在任何人都不知道的情况下用一种服务替换另一种服务。
也就是说，SOA的本质是解决应用间耦合的问题，保证在不影响其他应用的前提下进行软件的变更。可以说其理念非常好、非常先进，只是缺乏行之有效的实践手段，往往将SOA演变成了产品推销的商业行为。
那么通过以上的理解，我们可以将微服务看成是SOA方法的一种最佳实践，通过采用微服务设计能够实现每个服务应用的独立变更，并且不会对其他应用乃至整体造成影响，也就是实现SOA的目标。
微服务设计的关键
微服务设计的关键就是要做到可独立部署，即一个服务的变更、部署及发布，不影响也不需要重新部署任何其他的服务。
可独立部署初看起来比较简单，但实际上要达到这个目标需要满足服务间是完全松耦合的，否则是做不到独立部署的。那么问题就来了，怎么才叫松耦合的服务呢？
答案是服务自身要面向业务高内聚，而不是我们习惯的面向技术能力的高内聚。怎么理解这句话呢？这就需要谈一谈分层架构设计，相信在过去开发和设计中，我们用的最多的就是分层架构设计方法，非常典型的就是三层架构设计。
分层架构倡导的就是技术能力的高内聚，表现层聚焦的如何给用户进行UI展现；业务层聚焦的是如何处理表现层的请求；数据层聚焦的是如何高效存储和查询。这种分层架构的设计实际上遵循的也是“低耦合、高内聚”的设计原则，期望一层的变动不会对其他的层级造成影响。
但是实际情况并非如此，比如业务发生了变动，要求我们在前端页面增加一个按钮，要求用户喜欢作者的文章时，点击按钮来表示“喜欢”。期望是只影响表现层，但是我们有开发经验的都会认识到，增加这一个按钮在业务层需要增加相应的接口以及处理逻辑，在数据层需要增加相应的数据表或者数据字段用来存储用户的行为，也就是各个层级之间实际是相互影响的。
那么我们再来看一下什么叫面向业务的高内聚，情况确实就不太一样了。
上图每一个方块是一个业务高内聚的服务，假设用户服务提供的是用户注册、个人信息维护等能力；文章服务提供发布文章、浏览文章、评论文章等能力；视频服务提供视频发布、视频浏览、视频点评等能力。那么这时候再看实际上上面的业务变动就只会影响“文章服务”这个服务，其他服务不会受到影响。
要做到业务高内聚，实际上关键就在于划定稳定、清晰的业务边界，也就是围绕业务领域进行微服务的建模，这时候“领域驱动设计（Domain Driven Design，DDD）”是一个很好的选择。
另外，通过上面的说明，我们也能够知道，实际上每个微服务实际上不只是只能够包含后端的服务接口，而是可能需要包含前端展示的UI。也就是说，每个微服务可以应用分层架构的方法进行设计和实现。
关于微服务的大小
理解了微服务设计的核心关键在于构建稳定和清晰的服务边界，也就是面型业务的高内聚，那么我们也就不需要过分执着于微服务的服务究竟要有多大了。业界也没有标准答案，引用书中的话讲，“你能理解的服务有多大，那么微服务就可以是多大”。
同时相比关注微服务大小的话题，我们需要关注的是下面两个问题：
1、你能hold住多少个微服务？按常理理解，服务数量越多，复杂性越高，出错概率也就越高。
2、你能够定义出多少个稳定且清晰的服务边界？
所以，就像“1千人心中住着1千个哈姆雷特”一样，微服务设计并没有标准答案，还是要结合自身组织以及业务的特点进行划分和设计。
微服务架构的优势
1、技术自由
前面讲到每个服务都是独立的个体，那么也就不需要像传统的单体架构那样整个大平台必须保证技术统一。这时候每个微服务小团队就可以按照各自的技术强项以及业务场景选取合适的技术，从而提高整体的开发效率
2、鲁棒性
提高应用鲁棒性的关键是构建应用间的“隔水板”，即如果一个系统组件宕掉了，但是能够将这个错误进行隔离没有产生级联效应，从而保证系统的其他部分能够继续正常工作。
而我们前面说的，微服务天然就具备的这样的“隔水板”，即他们彼此之间稳定且清晰的服务边界。
3、弹性
相比于单体应用，只能进行完整应用的扩展部署，微服务可以做到每个服务的独立扩展和伸缩，使得应用整体更加弹性。
4、易发布
就像“哪里不会点哪里”一样，微服务能够做到“哪里变了发哪里”。
5、组合编排
由于每个服务是业务高内聚的，不同的业务之间可以进行灵活组合，从而创造出更多的可能性，降低创新成本。
不能盲目的技术崇拜
就像书中说的，包括我之前选用微服务架构一样，我们选用微服务架构的主要原因是被上面所说的各种好处所吸引，在应用还没有成型，还没有用户的情况下就考虑应用需要具备分布式的特性，以能够支撑大规模、海量并发的情况。这实际上是一种脱离实际的过度设计，也是一种技术崇拜。
实际上单体应用架构也是一种很好的架构选择，单体架构的优势也很突出：
1. 部署简单
2. 容易监控和维护
3. 问题定位更简单
这实际上，在我们开发新产品或者企业在初创阶段是很好的选择，因为这可以让我们将更多的精力放在业务上，而不是用在微服务的维护和排错上。
选择微服务架构，也要付出相应的代价，这就包括：
1. 开发者体验问题：因为服务数量变多了，开发者很难在开发机上将所有服务都运行起来，这就意味着，可能只能了解到局部。
2. 技术过载问题：像上面说的，技术自由了，代价就是技术管理更复杂了。
3. 监控和问题定位问题：分布式架构导致信息分散、日志分散，这就给监控和问题定位都造成很大的麻烦。
4. 安全问题：相比于单体架构，微服务架构更多的依赖网络进行消息传递，可能带来消息泄露带来的安全性问题。
5. 测试问题：微服务比较分散，导致很难进行很大范围的测试覆盖。
6. 延迟问题：相比于单体架构进程内的方法调用，微服务需要通过网络进行消息的流转传递，这必然会造成延迟性。
7. 数据一致性问题：一次请求通常需要经过多个服务，同时数据也要在多个服务间流转，这会带来数据一致性问题。
所以，我们需要理性的选择微服务，最好的办法是逐步迭代的向微服务进行过渡。
基于上面强调的微服务的独立性设计原则，那么我们很容易判断新产品以及初创阶段的产品不宜采用微服务，因为这时候业务边界并不清晰，很容易频繁的发生变化，从而导致每个服务的大量变更。
总结
微服务架构是SOA的一种最佳实践方法，一个重要的设计原则就在于保证每个服务的独立性。这个独立性一方面是微服务的优势，另外一方面也是我们在进行微服务架构设计时需要重点关注的设计原则。
那么回过头来看我们当时采用的微服务架构，只是照猫画虎，主要破坏的原则就是“独立性”原则，也就是业务边界的不清晰。
通过本文，让我对微服务架构有了更清晰的认识，也对于我们数据中台的架构有了新的理解。实际上，巧合的是我们的数据中台在设计上是能够与微服务架构的设计理念完全匹配的，这也算是意外收获吧，哈哈。