【话题讨论】理解微服务架构，实践云原生应用！
话题背景：
微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。
讨论内容：
1.微服务的定义？微服务需要“微”到什么程度？2.微服务的重大优势是什么？它是未来吗？3.微服务在实践过程中最大的难点是什么？4.微服务、容器技术两者的关系？两者结合带来什么新趋势？5.怎么处理微服务与外部相连，以及获取数据？ 6.微服务与容器结合会发展出新趋势--Cloud Native，什么是Cloud Native？（可选答）
活动时间：2019年7月30日-2019年8月18日
奖项设置：
一等奖1名：2019中国系统架构师大会 门票1张 二等奖3名：中国系统架构师大会（SACC）十周年纪念T恤一件 三等奖若干：50个 IT168文库金币
备注：CU论坛与ITpub话题讨论答案同步筛选，希望大家积极参与哦。
2019年10月31日~11月2日，由 IT168 旗下 ITPUB 企业社区平台主办的第十一届中国系统架构师大会（SACC2019)将在北京隆重召开。自2009年举办以来，大会云集了国内 CTO、研发总监、高级系统架构师、开发工程师和IT经理等技术人群，与会规模超千人。 本届大会继续沿用四大主线并行的演讲模式，设置业务系统架构设计、大数据平台架构设计、数字化转型实践和开源架构设计四大主线，共1个主会场，20个技术专场，100+来自互联网、金融、制造业、电商等领域嘉宾，将为广大参会者提供一场最具价值的技术交流盛会。
SACC2019 中国系统架构师大会，期待您的报名参与！报名链接：http://sacc.it168.com/
欢迎大家踊跃参与话题讨论哦~前排占楼 1.微服务的定义？微服务需要“微”到什么程度？
（1）每一个微服务是一个独立的自治系统，不依赖外部组件，能够独立运行；（2）对外只能通过API提供服务或者获取服务；（3）粒度足够小。微服务的粒度与团队组织方式是相关，与业务功能的构成相关，与数据相关。在业务功能方面，尽量做到一个模块中的业务高度类聚集，和外部模块做到松耦合，获取灵活性；在数据方面，一个微服务尽量不要和外部频繁的交互数据，大量的API交互对性能和可靠性都有影响。
2.微服务的重大优势是什么？它是未来吗？
微服务，是一种去中心化的架构。一般和更细粒度的容器配合使用，天生自带很强的共生性。从早期的集中式架构，到分布式架构，再到现在更细粒度化的微服务，其实一直朝着去中心化的趋势发展，具备更强的灵活性以及更适合云的特点。微服务是未来一种非常主要的、应用广泛的架构，但并不一定说它会统治一切。微服务化更适合无状态、高迭代的业务场景。
3.微服务在实践过程中最大的难点是什么？
微服务在实践过程中，最大的问题是团队之间的运作和管理。康威定律提到，有什么样的团队组织方式，就有什么样的业务架构。业务架构，是和团队组织架构相匹配的，当我们把一个大的系统，拆分成小的服务时，团队会随之变化。团队成员需要适应微服务的开发模式，微服务对每个程序员有着更高的要求。微服务实践的难点不在于没法拆分，难点在于很多人的思想停留在以前的架构思想下。建议逐步改造、持续迭代地改造架构。新业务、新团队可以独立地采用微服务化运作。
4.微服务、容器技术两者的关系？两者结合带来什么新趋势？
微服务是一种架构思想，而容器，或者说以Docker为代表的容器技术，是一种运行载体。容器天生适合细粒度的微服务，容器管理和分发需要Docker的支持。两者结合，就是去中心化思想的实践。伴随互联网与云计算的发展，什么样的架构或者产品研发模式是适合云模式的？是传统的集中式架构吗？分布式架构吗？现在创业型公司的特点：完全基于云端，轻资产，小团队作战，快速的产品迭代。为了适应这些特点，必须基于云的原生特点去设计应用架构，所以微服务和容器发展的新趋势，就是去实践Cloud Native。
5.怎么处理微服务与外部相连，以及获取数据？
微服务是通过API对外提供服务，本身是一个独立的自治系统，所以不存在需要与很多数据中心相互连接的情况；如果需要通讯，直接适用公网连接就可以。
换句话说，微服务和微服务之间的数据通讯是通过API调用的。没有所谓的内部的进程间、共享信号、共享内存队列的模式。一个微服务对外提供的服务一定是封装好的、接口式的。
6.微服务与容器结合会发展出新趋势--Cloud Native，什么是Cloud Native？
在云时代，全部应用都基于云去构建，并不适合套用传统的研发模式。Cloud Native是指云原生的应用架构，是专门针对云的架构。它主要包括三个部分，一种全新的架构思想（微服务），一种业务运行管理模式，以及一种团队组织管理方式。关乎DevOps、小团队、敏捷开发。Cloud Native既不是一个新的技术，也不是一套新的架构，而是产品研发、运营的全新模式。它是在云的生态场景生长出来的，和云的关系是一种鱼和水的关系。
微服务的定义？微服务需要“微”到什么程度？
就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，
并使用轻 量级机制通信，通常是 HTTP RESTFUL API。这些服务围绕业务能力来划分构建的，并通过
完全自动化部署机制来 独立部署。 这些服务可以使用不同的编程语言，以及不同数据存储技术，以保
证最低限度的集中式管理。
微服务的重大优势是什么？它是未来吗？
优点提升开发交流，每个服务足够内聚，足够小，代码容易理解；服务独立测试、部署、升级、发布；按需定制的DFX，资源利用率，每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上；每个服务按需要选择HA的模式，选择接受服务的实例个数；容易扩大开发团队，可以针对每个服务（service）组件开发团队；提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；新技术的应用，系统不会被长期限制在某个技术栈上
微服务在实践过程中最大的难点是什么？
微服务在实践过程中，最大的问题是团队之间的运作和管理的问题.因为微服务，对每个程序员的要求是比较高的：每个程序员的权责会更明显，需要标准化接口、书写规范文档，而且一般需要有DevOps的工作。 怎么处理微服务与外部相连，以及获取数据？
在设计时就需要考虑到微服务有哪些数据需求（见问题一的第二小问）：微服务都是通过API对外提供服务，本身是一个独立的自治系统，所以不存在需要与很多数据中心相互连接的情况；如果需要通讯，直接适用公网连接就可以了。 微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程
微服务的重大优势是什么？它是未来吗？
每个服务都比较简单，只关注于一个业务功能。
微服务架构方式是松耦合的，可以提供更高的灵活性。
微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。
每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。
微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。
微服务架构的缺点有啥呀？ suliver 发表于 2019-08-02 16:35
微服务架构的缺点有啥呀？
运维开销及成本增加：整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。
必须有坚实的DevOps开发运维一体化技能：开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。
隐式接口及接口匹配问题：把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。
代码重复：某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。
分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。
异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。
可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。
希望对你有所帮助
页:
[1]
2